¥1 

f S L:\DMS\7574\M-3423_U\0135864.04A - 



10 



30 



Dale of Signati/e v -"' ~ 




A METHOD AND ARCHITECTURE FOR AN INTERACTIVE TWO-WAY 
DATA COMMUNICATION NETWORK 
Alain Rossmann 



&> CROSS R EFERENCE TO MICROFICHE APPENDIX 

Appendix A, which is a part of the present 
disclosure, is a microfiche appendix consisting of six 
sheets of microfiche having a total of 369 frames. 
Microfiche Appendix A is a listing of one embodiment of 
the client module of this invention, which is described 
more completely below, and a server, as described more 
completely below, to communicate and interact with the 
client module of this invention. 

A portion of the disclosure of this patent 
15 document contains material, that includes, but is not 
limited to, Microfiche Appendix A, Appendix I, 
Appendix II, and Figures 10A to 10T, which is subject 
to copyright protection. The copyright owner has no 
objection to the facsimile reproduction by anyone of 
2 0 the patent document or the patent disclosure, as it 

appears in the Patent and Trademark Office patent files 
or records, but otherwise reserves all copyright rights 
whatsoever. 

2 5 BACKGROUND OF THE INVENT TON 
Field of the Invention 

This invention relates generally to data 
communications, and in particular to two-way data 
communication devices including a cellular telephone, a 
two-way pager, and a telephone that permit a user to 
interface with and interact with a server on a computer 
network . 

Descripti on of Related Art 

For at least the last five years, the wireless 
35 communication industry has tried to merge computing 
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with wireless communications. This industry wide 
effort has held the promise of bringing software 
intelligence to telecommunication devices including 
mobile wireless communications devices such as cellular 
5 telephones and two-way pagers as well as standard 
telephones . 

After years of research and development, and 
hundreds of millions of dollars' investment by some of 
the largest companies in the field such as Motorola, 

10 AT&T, Sony, Matsushita, Phillips and IBM, the results 
have been nothing but disappointing. Typically, the 
intelligent communication devices resulting from these 
efforts include both the hardware necessary for a 
computer module and the hardware for a wireless 

15 communications module. Examples of such products are 

Simon from IBM and Bell South, MagicLink from Sony, and 
Envoy from Motorola. 

Fundamental design and cost problems arising 
directly from the approach taken by the designers of 

2 0 these intelligent communication devices have limited 
widespread market acceptance of these devices. The 
combination of a wireless communication module with a 
computing module leads to a device that is too bulky, 
too expensive, and too inflexible to address the market 

2.-5* requirements. 

The combination of the two modules is too large 
and too heavy to fit in a user's pocket. Pocket size 
is a key requirement of the mobile communication market 
which remains unmet by these devices 

30 In addition, the cost of these devices is close to 

the sum of the cost of the computer module and of the 
communications module, which is around a one thousand 
dollar end-user price. Market research indicates that 
the market for intelligent wireless communications 

35 devices is at prices around $300. Even with a 20% 

compound cost decline, it would take five years for the 
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combination units to meet today's customers' price 
requirements- It is therefore unlikely that devices 
designed by combining a computer and a wireless module, 
no matter how miniaturized and cost reduced, can 
5 satisfy the cost requirement of the market during this 
decade . 

To succeed in the market place, intelligent 
wireless communication devices must be able to support 
a wide variety of applications specific to each market 
10 segment. Typically, these applications must be added 
to the device by the end-user after purchase. Thus, 
the device must provide a method for loading the 
initial application and for subsequent updating of the 
application . 

15 The price sensitivity for intelligent 

communication devices and the size limitations means 
that an intelligent communication device cannot support 
the amount of core memory (RAM) , a hard disk or non- 
erasable memory, or a traditional floppy disk drive, 

20 commonly found on computers. These limitations close 
the traditional routes for delivering new applications 
or updates to intelligent communications devices. 

As a result, the current crop of intelligent 
communication devices run only the few applications 

25 which were burned into their ROMs at the factory or 

which are contained in a ROM card plugged into a slot 
designed for this purpose. This scheme lacks the 
flexibility needed to run the thousands of applications 
required to address the fragmented requirements of the 

3 0 market and provides no simple method for updating the 
applications after the device has been sold. 

Two other communication oriented attempts at 
bringing intelligence to telephones are Short Messaging 
Service (SMS) and Analog Display Service 

35 Interface (ADSI) . SMS specifies how messages are 

delivered to and from a cellular telephone and how the 
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cellular telephone should store the messages. SMS also 
defines some simple processing which the cellular 
telephone can perform on the message, such as calling a 
telephone number embedded in the message. 

SMS's architecture is similar to that of paging 
networks with the difference that devices implementing 
the SMS architecture operate over the control channel 
of the cellular telephone network. SMS is deployed 
primarily in Europe over the GSM network. 

SMS messages are not delivered in real time. The 
time delays can range from 30 seconds up to 10 minutes, 
which makes SMS unsuitable for real time applications. 
The main purpose of SMS is the delivery of messages. 
SMS does not specify an application protocol or 
cellular telephone application module which further 
restricts its usefulness in running applications on 
cellular telephones. After a few years of deployment 
in Europe, SMS implementations have been limited to 
notification services such as two-way paging and voice 
mail notification. 

SMS as a medium is unsuited to building 
applications which allows the retrieval, manipulation, 
and storage of information. This is the reason why the 
industry giants have not turned to SMS in their quest 
to add intelligence to cellular telephones, but have 
consistently attempted to combine a computer module 
with a wireless communications module. 

ADSI was designed as an extension to Interactive 
Voice Response Systems. ADSI allows a smart telephone 
with a small screen to display prompts to assist users 
in choosing among various options. By using visual 
prompts instead of cumbersome voice prompts, ADSI is 
thought to make the use of interactive voice services 
easier and faster. 

ADSI allows data to be sent from the service 
provider to the telephone in the form of screens. ADSI 
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also allows the telephone to respond through touch tone 
signaling with a special coding to describe the full 
alphanumeric character set. With ADSI, a telephone is 
primarily a passive device. Services send text screens 
5 to the telephone, and the telephone sends back short 
strings indicating the choices the user made from the 
text screen. 

ADSI makes no provisions for performance of 
processing in the telephone. As a result, ADSI 

10 generates a high traffic load on the telephone network 
since each user input is sent back to the service for 
processing. This makes ADSI unsuitable for wireless 
networks where bandwidth is at a premium and "air 
efficiency" is one of the most sought after qualities. 

15 The lack of processing capability in the telephone and 
the high bandwidth requirements of ADSI have prevented 
it from being considered by the industry for 
implementing intelligent wireless devices. 

Up to now, intelligent communication devices have 

20 combined a computing module with a wireless 

communications module'*; However, to gain widespread 
acceptance, a two-way data communication device with 
processing capability and the ability to run a wide 
variety of differing user applications is needed. In 

2 5 addition, such a device should be comparable in size, 

cost, and weight to a cellular telephone. 

SUMMARY OF THE INVENTION 

According to the principles of this invention, the 

3 0 prior art limitations of combining a computer module 

with a wireless communication module have been 
overcome. In particular, a two-way data communication 
device of this invention, such as a cellular telephone, 
two-way pager, or telephone includes a client module 
35 that communicates with a server computer over a two-way 
data communication network. The principles of this 
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invention can be used with a wide variety of two-way- 
data communication networks. For example, two-way data 
communication networks for cellular telephones that may 
be used include a cellular digital packet data network 
5 as well as TDMA, CDMA, and GSM circuit switched data 
networks; and the AMPS analog cellular network with a 
modem. Similarly, for two-way pagers, two-way data 
communication networks include PACT, the new AT&T 
endorsed two way paging standard, or other priority 

10 two-way paging networks with data transport capability. 
The two-way data communication network for a telephone 
is the public switched telephone network. 

Using the two-way communication device that 
includes the client module, a user can provide 

15 information to the server computer, retrieve 

information from the server computer, provide data to 
an application on the server computer -which uses the 
data and provides information to the two-way 
communication device, or sends the information to 

20 another location. The? functionally provided to the 
user of the two-way communication device is limited 
only by the applications available on a server computer 
that is accessible to the user over the two-way data 
communication network. 

25 This invention allows for the first time two-way 

communications devices such as cellular telephones, 
two-way pagers, and telephones to become open 
application platforms which in turn empowers software 
developers to deliver value-added applications and 

30 services to any two-way communication device that 

incorporates the principles of this invention. This is 
a radical shift from the current situation where 
telephones and two-way pagers are closed, proprietary 
systems. Consequently, an even playing field is 

35 created for the market to invent new uses for two-way 
communication devices and for two-way communication 
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networks. Any entity from corporations to individuals 
can make new applications available to the installed 
base of two-way data communication devices that include 
this invention without physical modification or 
5 addition to the two-way communication device. Years 
after purchase, a two-way communication device 
incorporating this invention will run all the 
applications which were developed since its purchase. 
Further, all these applications are available 

10 without the end user having to add anything or make any 
modification to the two-way communication device. Also, 
the applications are independent of the two-way data 
communication network. The applications do not depend 
on any feature of the two-way data communication 

15 network. Thus, the applications are unaffected by a 
change in the two-way data communication network. 

Also, the applications on the server computer are 
independent of the two-way data communication device 
with which the server 'computer is interacting. An 

20 application on the server computer can communicate with 
any two-way data communication device that includes the 
client module of this invention and a network interface 
module to transmit data over, and receive data from the 
two-way data communication network. These two features 

2 5 mean that an investment in developing an application is 

insulated from either advances in two-way data 
communication devices, or advances in two-way data 
communication network technology. 

As indicated above, the two-way data communication 

3 0 device of this invention utilizes a client module to 

transmit a message including a resource locator 
selected by the user over the two-way data 
communication network to a server on a server computer 
on the computer network. For example, the computer 
3 5 network can be a corporate wide area network, a 

corporate local area network, the Internet, or any 
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combination of computer networks. 

The server processes the message, i.e, executes 
the application addressed by the resource locator and 
transmits a response over the two-way data 
5 communication network to the two-way data communication 
device/ which stores the response in a memory. The 
client module interprets the response and generates a 
user interface using information in the response. In 
one embodiment, the user interface includes at least 

10 one user data input option that is associated with a 
resource locator. In another embodiment, the user 
interface is a display. 

The resource locator associated with the at least 
one user data input option can address any one of a 

15 wide variety of objects. In one embodiment, the 

resource locator associated with the at least one user 
data input option addresses an object on the server 
computer that transmitted the response. In another 
embodiment, the resource locator addresses an object on 

20 another server computer coupled to the two-way data 

communication network./ In yet another embodiment the 
resource locator addresses an object stored in the two- 
way communication device. 

When the user selects the at least one user data 

25 input option, the client module interprets the 

selection and if required, appends any input data to 
the resource allocator associated with the at least one 
user data input option. The client module transmits a 
message including the resource locator with any 

3 0 appended input data to the server computer. 

Alternatively, the resource locator with any appended 
data can be addressed to another server computer, or 
can address an object stored in the two-way 
communication device. If the resource locator 

35 addresses an object on a server computer, the client 
module provides the message to the network interface 




L:\DMS\7574\M-3423 U\0135864 \^*^ 





10 



'r: 15 



20 



25 



30 



module which in turn transmits the message over the 
two-way data communication network. 

Thus, in this embodiment, the message originally 
transmitted to the two-way data communication device 
included all the information necessary for the client 
module to generate the user interface, to associate the 
user selection and any data entered with a particular 
resource locator, and to transmit the appropriate 
resource locator in a subsequent message. The client 
module includes an interpreter that processed the 
information in the message- Since the message included 
all the information needed by the client module, the 
server computer that transmitted the message retained 
no state information concerning the message. 
Consequently, the server computer is defined as a 
stateless server computer. 

An important aspect of this invention is that the 
message includes all information necessary for the 
client module to generate the user interface and a 
particular user interface can be independent from other 
user interfaces. Unlike prior art systems that gave 
the user a predetermined menu from which to select 
items, or limited the user to an E-mail like format, 
according to the principles of this invention, the user 
interfaces and possible interactions available to the 
user are determined only by the applications that 
developers make available. The possible interactions 
and user interfaces for one application can be totally 
different and independent from the possible 
interactions and user interfaces of another 
application. Thus, a cellular telephone, two-way 
pager, and a telephone all truly become an open 
platform. 

These features of the invention are a significant 
departure from prior art systems. Typically, in the 
prior art, use of a particular application on a 
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particular platform required that the application be 
compatible with the operating system on that platform. 
Further, each time a new version of the application was 
released, the user was required to take steps to update 
5 the application on the user's platform. Further, if 
the user of the platform did not modify the operating 
system as new versions of the operating system were 
released, at some point in time, the platform would no 
longer be capable of processing a new version of an 

10 application that required a current version of the 
operating system. 

This invention eliminates these problems. As 
explained above, the client module in the two-way data 
communication device functions an interpreter. The 

15 application on the server computer provides all 

information necessary for the interpreter to generate a 
user interface on the two-way data communication 
device, and in response to user selections or data 
input using the user interface, to route messages to an 

20 appropriate server, i.e, either the server that sent 
the original information or another server. 

Thus, the client module only interprets this 
information and interacts, appropriately with the 
hardware of the two-way data communication device. 

25 Consequently, to update an application requires only 

changes on the server computer and not changes in each 
two-way data commuriication device that communicates 
with that server computer. This invention eliminates 
the usual requirement for distribution of application 

3 0 software, and application software updates to the end 
user of the two-way data communication device. 

In one embodiment, a two-way data communication 
system for communication between a server computer and 
a two-way data communication device selected from a 

35 group consisting of a cellular telephone, a two-way 
pager, and a telephone, includes a two-way data 
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communication network, a server computer coupled to the 
two-way data communication network, and a two-way data 
communication device coupled to the two-way data 
communication network. The server computer includes a 
5 two-way data communication interface module coupled to 
the two-way data communication network, and a server 
coupled to the two-way data communication interface 
module. The server receives a message including a 
resource locator from the two-way data communication 

10 network. The resource locator includes an address of 
the server computer and of an application on that 
server computer. The server processes the message using 
the resource locator. In this embodiment, the server 
transmits a response to the message over the two-way 

15 data communication network. 

The two-way data communication device, selected 
from the group consisting of a cellular telephone, a 
two-way pager, and a telephone, includes a network 
interface module coupled to the two-way data 

20 communication network, and a client, module coupled to 
the network interface module. The client module 
transmitted the message including the resource locator 
to the server over the fiwo-way data communication 
network. The client module also processes the response 

25 to the message from the server. The response includes 
information for a user interaction over the two-way 
data communication network. 

The client module of this invention is 
lightweight, and thus requires only lightweight 

3 0 resources in a two-way data communication device. 
Consequently, the client module can use existing 
resources in such a device and therefore does not add 
to the cost of the two-way data communication device. 
In one embodiment, the interpreter within the 

35 client module includes a plurality of managers 

including a user interface manager coupled to a display 
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of the two-way data communication device where the user 
interface manager handles interactions with the 
display. The user interface manager also is coupled to 
a keypad of the two-way data communication device and 
5 handle interactions with the keypad. Herein, a keypad 
can be a telephone keypad, the keys found on a two-way 
pager, or other data input interface of a two-way 
communication device. 

In one embodiment , the response generated by the 
10 server computer includes a plurality of resource 

locators and at least one of the plurality of resource 
locators includes an address to another server coupled 
to the communication network. 

According to the principles of this invention, a 
15 method for using a two-way data communication device, 
selected from a group consisting of a cellular 
telephone, a two-way /pager , and a telephone, to 
communicate with a server computer includes : 

generating a message by a client module in 

2 0 response to data entered by the user of a two-way 

data communication device coupled to a two-way 
data communication network, 

wherein the client module executes on a 
microcontroller of the two-way data 
25 communication device; and 

the message includes a resource locator; 

transmitting the message over the 
two-way data communication network to a 
server computer wherein the server 

3 0 computer is identified by the resource 

locator; 

executing an application on the server 
computer identified by the resource locator to 
generate a response to the message; and 
35 transmitting the response to a location 

identified by the application. 
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As indicated above the location can be the two-way 
communication device, another server computer, or some 
other device coupled to the server computer. 

5 BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 illustrates one embodiment of the airnet 
network of this invention that includes the two-way 
data communication devices of this invention. 

Figures 2A to 2H are illustrations of a series of 
10 screen displays of the two-way data communication 
device of this invention that illustrate one 
application of the principles of this invention. 

Figures 3A to 3F are illustrations of a series of 
screen displays of the two-way data communication 
15 device of this invention that illustrate a second 
application of the principles of this invention. 

Figures 4A to 41 are illustrations of a series of 
screen displays of the two-way data communication 
device of this invention that illustrate yet another 
20 application of the principles of this invention. 

Figure 5 illustrates another embodiment of the 
airnet network of this invention that includes the 
two-way data communication devices of this invention 
and an airnet network translator. 

2 5 Figure 6 is a block diagram of a mobile wireless 

communication device that includes the client and 
support modules of this invention. 

Figure 7 is a more detailed diagram of the mobile 
wireless communication device and a server computer 

3 0 within the airnet network architecture of this 

invention . 

Figures 8A to 8D are a process flow diagram 
showing the process performed by the client in the 
mobile wireless communication device and the server on 
3 5 the server computer of Figure 7. 

Figure 9 is a diagram of a mobile wireless 
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communication device of this invention that includes a 
novel predictive text entry system that is a part of 
this invention. 

Figures 10A to 10T are one embodiment of a letter 
frequency table. / 

Figure 11 is a process flow diagram for one 
embodiment of a data entry process that includes the 
novel predictive data entry process of this invention. 

Figure 12 is a more detailed diagram of the mobile 
wireless communication device and the airnet network 
translator within the airnet network architecture of 
the another embodiment of this is invention. 

Figure 13 is a process flow diagram showing the 
various processes performed by the airnet network 
translator of Figure 12 . 

Figure 14 is a diagram illustrating the various 
module managers included in one embodiment of the 
client module of this invention. 

Herein, objects with the same reference numeral 

are the same object^ Also, the first number of a 

/J / 

reference numeral/indicates the Figure where the object 
first appeared. ' 

DETAILED DESCRIPTION 

According to the principles of this invention, a 
novel airnet network 150, i.e., a two-way data- 
communication network, interconnects any one, any 
combination, or all of two-way data communication 
devices 100, 101, or 102, that each include this 
invention, with a wide variety of computer 
networks 12 0, 13 0, and 14 0, for example. As explained 
more completely below, each two-way data communication 
device 100, 101, and 102 can be configured to transmit 
data to and receive data from any desired combination 
of computers on computer networks 12 0, 13 0, and 14 0. 
Airnet network 150 is the two-way data communication 
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path from the two-way data communication device to the 
particular computer that is accessed by the user of 
that two-way data communication device. 

Each wireless communication device 100 that 
5 includes this invention can communicate over airnet 

network 150 with any server computer 121, 131, and 141 
on airnet network 150 that includes at least one 
application that communicates and interacts with the 
processes of this invention that are included within 

10 device 100. Thus, device 100 can access information on 
the computer network and provide information to the 
computer network. Similarly, a two-way pager 101, and 
a telephone 102 with a modem 103, that each include 
this invention, can communicate over airnet network 150 

15 with any of server computers 121, 131, and 141 that 

includes at least one application that communicates and 
interacts with the processes of this invention that are 
included within devices 101 and 102. 

As explained more completely below, an application 

2 0 on a server computer can be accessed by any two-way 
data communication device that can communicate with 
that server computer. The application is independent 
of the particular type of two-way data communication 
device that is used to access the application and 

2 5 independent of the particular two-way data 

communication network used. This means that a user can 
access an application from anywhere so long as the user 
has a two-way data communication device that can 
communicate with the server computer. 

3 0 In one embodiment, a process on wireless 

communication device 100 is configured as a client 
process and the applications on server computers 121, 
131 and 141 on airnet network 150, that communicate 
with the client process, are server processes. This 
3 5 architecture allows some of the processing burden to be 
moved away from cellular telephone 100, across airnet 
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network 150, to a server module on any computer on 
airnet network 150. 

Specifically, a wireless communication device 100 
e.g., a cellular telephone, with a telephone like 
5 keypad, communicates via a data capable cellular 

telephone network 110, e.g., a cellular digital packet 
data telephone network, with an application on a server 
computer on a computer network that has an interface to 
data capable cellular telephone network 110. For 

10 example, the computer network can be a corporate wide 
area network 120, a corporate local area network 130, 
or perhaps the Internet 14 0 . 

Similarly, a two-way pager 101 communicates via a 
two-way pager network 111 with an application on a 

15 server computer on a computer network that has an 

interface to two-way pager network 111. Again, for 
example, ( the computer network can be a corporate wide 
area network 12 0, a corporate local area network 13 0, 
or perhaps the Internet 140. Finally, a telephone 102 

20 communicates via a modem 103 and public switched 

telephone network' 112 with an application on a server 
computer on a contputer network that has an interface to 
public switched telephone network 112. As with the 
other two-way data communication devices, the computer 

25 network can be, for example, a corporate wide area 
network 120, a corporate local area network 130, or 
perhaps the Internet 140. 

In each of two-way data communication devices 100, 
101, and 102, the client process is stored as a client 

3 0 module in the device and the execution of the client 

module on a microcontroller in the device is sometimes 
referred to as the client process. The client process 
performs important processing functions locally. This 
allows the communication between the client process, 

35 hereinafter sometimes referred to as simply client, and 
the server process, hereinafter sometimes referred to 
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as server, to be minimized and the server computing 
requirements to grow slowly as the number of clients, 
i.e., users, grows. 

The client module is small, e.g., under 64 KByte, 
5 and requires only low processing power congruent with 
the memory chips and built-in microcontrollers in two- 
way data communication devices such as cellular 
telephone 100, two-way pager 101, and telephone 102. 
Thus, unlike the prior art attempts at an intelligent 

10 telephone, the cost, size, and battery life of either 

cellular telephones, two-way pagers, or telephones that 
incorporate this invention are not adversely affected. 

While client/server architectures have been used 
extensively in computer networks, a client /server 

15 architecture implemented using two-way communication 
data devices such as cellular telephone 100, two-way 
pager 101, or telephone 102 yields, new and unexpected 
results. This invention allows for the first time a 
wide variety of two-way data communication devices 

20 including but not limited to cellular telephones, two- 
way pagers, and telephones to become open application 
platforms which in turn empowers software developers to 
deliver value added applications and services to any 
two-way data communication device which incorporates 

25 the principles of this invention. 

This is a radical shift from the current situation 
where cellular telephones, two-way pagers, and 
telephones are closed, proprietary systems. 
Consequently, an even playing field is created for the 

3 0 market to invent new uses for cellular telephones and 
data capable cellular networks, for two-way pagers and 
two-way pager networks, and for telephones on the 
public switched network. 

Any entity from corporations to individuals can 

35 make new applications available to the installed base 
of data ready cellular telephones, two-way pagers, and 
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telephones, that include this invention without 
physical modification or addition to the devices. 
Years after purchase, a two-way data communication 
device with this invention can run all the applications 
5 which were developed since its purchase. Further, all 
these applications are available without the user 
having to add anything or make any modification to the 
two-way data communication device. These features of 
the invention are a significant departure from prior 

10 art systems. Typically, in the prior art, use of a 
particular application on a particular platform 
required that the application be compatible with the 
operating system on that platform. Further, each time 
a new version of the application was released, the user 

15 was required to take steps to update the application on 
the user's platform. Further, if the user of the 
platform did not- modify the operating system as new 
versions of the operating system were released, at some 
point in time, the platform would no longer be capable 

2 0 of processing a new version of an application that 

required a current version of the operating system. 

Also, small devices;; such as cellular telephones 
or pagers, usually do -not "Have card slots, floppy or 
hard disk drives, or other means commonly found on 
25 computers to add or update applications. This 

limitation has led prior art attempts at intelligent 
communication devices to design closed systems with 
fixed functionality. Such devices can neither adapt 
nor be adapted to the fast changing requirements of the 

3 0 market place and so have not met with market success. 

This invention eliminates these problems. The 
client process in the two-way data communication device 
functions an interpreter. The application on the 
server computer provides all information necessary for 
35 the interpreter to generate a user interface on the 

two-way data communication device, and in response to 
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user selections or data input using the user interface, 
to route messages to an appropriate server, i.e, either 
the server that sent the original information or 
another server* 



information and interacts appropriately with the 
hardware of the two-way data communication device. 
Consequently, to update an application requires only 
changes on the server computer and not changes in each 

10 two-way data communication device that communicates 

with that server computer. This invention eliminates 
the usual requirement for distribution of application 
software, and application software updates to the end 
user of the two-way data communication device. 

15 For example, if initially, two-way pager 101 

receives a response to a message from an application on 
server computer 121 on corporate wide area network 120, 
the interpreter in two-way pager 101 generates a user 
interface on display screen 106 using information in 

20 the message. As described more completely below, 

options presented in the user interface can allow the 
user to access information, or provide information to 
any one, any combination of, or all of networks 12 0, 
130, and 140. 

25 Specifically, in the response to the message from 

two-way pager 101, the application initially accessed 
on server computer 121 included resource locators for 
applications on each of networks 120, 130, 140, 
typically common gateway interface programs, accessible 

30 to the user of pager 101 as well as information 

required to generate the user interface. Consequently, 
when the user makes a particular selection or enters 
data, the interpreter accesses the appropriate resource 
locator and appends any necessary data to the resource 

3 5 locator. The client transmits a message including the 
resource locator to the appropriate server. 



5 



Thus/ the client process only interprets this 
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As shown by this example, the applications on 
networks 12 0, 13 0, 14 0 send to the two-way data 
communication device all information necessary to 
generate a user interface, and to process all user 
5 input. Consequently, only an application must be 

changed to update the information provided to the two- 
way data communication device. 

In addition, since all the information needed by 
the client to generate a user interface and all 

10 information necessary for the client process to respond 
. to any input data is included in the message, the 
computer server does not retain any state information 
concerning the information transmitted to the client 
process. Consequently, the computer server is 

15 stateless. 

Each two-way data communication device 100, 101, 
and 102 that utilizes airnet network 150, includes a 
data communication capability, a display screen, 
preferably a multi-line display screen, and storage 

20 capability for the processes of this invention in an 
on-board memory, and for the message being processed. 
Nearly every data capable cellular telephone, e.g., a 
telephone that utilizes a cellular digital packet data 
network, includes .excess on-board memory capacity and a 

25 multi-line display screen. These hardware resources 
are often available, but unused in a data capable 
cellular telephone because of the indivisibility of 
memory chip packages. The inclusion of the processes 
of this invention in such cellular telephones therefore 

30 has very little effect on the cost, size, and power 

consumption of the cellular telephone. Similarly, the 
inclusion of the processes of this invention in two-way 
pagers and telephones, that include a microcontroller 
and memory, has very little affect on the cost, size, 

35 and power consumption of these devices. 

Thus, unlike prior art approaches that attempted 
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to combine a computer module and a wireless 
communication module in a single package, this 
embodiment of the invention preferably utilizes the 
memory and processing power that currently exists in 
5 the cellular telephone 100, two-way pager 101, 

telephone 102 or other wireless or landline two-way 
data communication devices. This approach limits the 
cost of the resulting device and overcomes many of the 
problems of the prior art devices, e.g., the size and 

10 weight of the two-way data communication device is not 
changed, and, as explained above, updating user 
applications is removed from cellular telephone 100, 
two-way pager 101, and telephone 102. 

In particular, unlike devices produced by previous 

15 industry attempts at combining computing modules and a 
wireless cellular module, two-way data communication 
devices which incorporate this invention are size and 
cost competitive with voice -only telephones and can, 
for the first time, satisfy the market cost and size 

20 requirements for an intelligent cellular telephone, for 
example . 

The incremental cost of supporting interactive 
applications on cellular telephone 100, two-way 
pager 101, and telephone 102 is reduced to at most a 

25 slightly larger screen that is required to display the 
application to the user. This is a fraction of the 
cost of adding a complete computer module to a cellular 
telephone, for example. 

The incremental power consumption required to 

3 0 support this invention is also very small, as the 
incremental memory and screen required are small 
consumers of power compared to the cellular radio 
itself. Intelligent two-way data communication devices 
built according to the principles of this invention are 

35 not expected to have a significantly lower battery life 
than standard cellular telephones, or two-way pagers, 
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for example . 

The configuration and processes of the client 
process in two-way data communication devices 100, 101, 
and 102 are similar when the differences in the devices 
5 and the two-way data communication network over which 
the devices communicate are considered. Consequently, 
in the following description, the operation of data- 
ready cellular telephone 100 is considered. The same 
or similar operations can be performed on two-way data 

10 communication devices 101, and 102. The main 

difference is that some device dependent features 
within the client module must be changed to accommodate 
the particular hardware used in the two-way 
communication device. However, the client module 

15 architecture described more completely below limits the 
number of changes that must be made. 

As indicated above, in response to user actions, 
wireless communication, device 10 0 transmits a message, 
typically a data request, to a server computer 121 on 

2 0 computer network 12 0 and receives a response to the 

message. Alternatively, the user action can result in 
directions to server computer 121 on computer 
network. 120 to transmit the response to the message to 
another location or to another user. Also, wireless 
25 communication device 100 can receive a message from any 
one of the computers coupled to airnet network 150. 

An important aspect of this invention is that the 
client module interpreter in wireless communication 
device 100 generates a user interface by which the user 

3 0 can both initiate and receive messages from a variety 

of applications. The interactions take place in real- 
time and are not limited by the client module 
interpreter. The uses of wireless communication 
device 100 are limited only by the availability of 
35 applications on server computers. 

The applications available are determined by 
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application developers. Prior to considering one 
implementation of the invention in further detail, 
several illustrative examples of applications that can 
be implemented according to the principles of this 
5 invention are described. These applications are 

illustrative only and are not intended to limit the 
invention to the particular applications and features 
described. 

In one use, the user configures cellular 
10 telephone 100 to access server computer 121 on XYZ 

corporate wide area network 120. In response to the 
access by the user, server computer 121 transmits a 
card deck to cellular telephone 100 over data capable 
^3 cellular telephone network 110. As explained more 

iu ; 15 completely below, a card deck includes one or more 

*Q cards, and each card is interpreted by the client 

module to generate a user interface screen. 
lU In the embodiment illustrated in Figure 2A, the 

B=B initial card deck transmitted to cellular telephone 100 

\*k 2 0 includes an introductory display card and a choice 

IZl card. Figure 2A is an example of introductory screen 

[l* display 200 that is generated on display screen 105 by 

^0 the client process in cellular telephone 100 by 

*** interpreting the display card. As used herein, a 

25 display screen is the physical display apparatus in a 
two-way communication device. A screen display is the 
image presented on the display screen. 

In this embodiment, display screen 105 is a pixel 
display that displays graphics. In another embodiment, 
3 0 display screen 105 displays only text and so the 
graphics would not appear on display screen 105. 
Screen display 200, and other screen displays described 
more completely below, include a horizontal arrow, 
i.e., a multi-card deck indicator, to communicate to 
3 5 the user that the current deck includes another card. 

The inclusion of screen indicators, such as the multi- 
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card deck indicator, to communicate with the user is 
optional. The functionality of this invention is 
independent of such screen indicators . 

When the user presses a predetermined key, or key 
5 sequence, the client process in cellular telephone 100 
interprets the next card in the card deck, i.e., the 
choice card, and in turn generates a menu 201 (Fig. 2B) 
of items that can be accessed by the user. In this 
embodiment, each of the menu items is available on 
.10 server computer 121 to the user who, in this example, 
is a representative of XYZ corporation visiting ABC 
Designs . 

As explained more completely below, each of the 
q menu items is associated with a resource locator that 

jfi 15 includes an address of the particular object associated 

Iq with that menu item, typically an address to a common 

)B gateway interface program on server computer 121. In 

lZ general, a resource locator includes ah address and may 

H include appended data. The address can be to a local 

2 0 object within the two-way data communication device or 
jU to a remote object on a server computer. As is known 

^ to those skilled in the art, the common gateway 

^ interface is an Internet standard that is used to 

|H dynamically generate information, e.g., cards. In view 

25 of this disclosure, other techniques to generate 
dynamic cards could be used. 

Initially, the highlighting of the first line of 
menu 201 is not present. When a key on the keypad of 
cellular telephone 100 is pressed, the menu item 
30 corresponding to that key is highlighted on screen 105. 
Thus, menu 201 shows the first item highlighted to 
indicate that the one key was pressed by the user. 
However, highlighting a selected item is a feature that 
is specific to this example, and in general is not 
35 required to implement the invention. Other methods can 
be used to indicate the user's choice on display 
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screen 105 such as an arrow pointing at the choice, if 
such an indication is desired. 

After the one key is pressed, the user presses a 
predetermined key, e.g., an enter key, to verify the 
5 selection. Alternatively, in another embodiment, the 

verification of the selection is not required. In both 
embodiments, the resource locator for the selection is 
transmitted to server computer 121 by the client 
process in cellular telephone 100 over data capable 

10 cellular telephone network 110. In response to the 
selection, server computer 121 processes the message 
containing the selection, and in this embodiment, 
transmits another card deck to cellular telephone 100. 
The client process in cellular telephone 100 

15 interprets the first card in the deck received from 
server computer 121, which is a choice card, and 
generates a screen display 2 02, that includes a second 
menu as illustrated in Fig. 2C, on display screen 105. 
Initially, none of the items in the second menu are 

2 0 highlighted. 

Notice that. screen display 202 includes a header, 
that describes the > selection made by the user on screen 
display 201, in addition to the second menu of choices 
available to the user. A multi-display screen card 

25 indicator 203, e.g., in this embodiment, a hand icon 
with a finger pointing down, shows that the screen 
associated with the current choice card includes 
additional items that are not shown on display 
screen 105. Herein, a screen can be larger than the 

30 number of lines available on display screen 105 and so 
the user must scroll the screen display to view the 
complete screen. 

Thus, to view the additional items, the user 
presses a first screen scroll key, e.g., a next key, on 

35 cellular telephone 100. In this embodiment, when the 
first screen scroll key is pressed, each line of the 
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display is rolled up one line. The resulting display 
has an icon with a finger pointing up (not shown) if 
the menu requires only two screen displays. If the 
menu requires more than two screen displays, the second 
5 screen display of the menu would have two icons, one 
with a finger pointing up, and another with a finger 
pointing down. To scroll between the various lines in 
the second menu, the user uses the first screen scroll 
key, and a second screen scroll key. 

10 If the user displays the last line of a card, 

e.g., the last line in the second menu, and presses the 
first screen scroll key nothing happens. In this 
embodiment, the user must make a choice before the next 
card is available. 

15 Screen display 202 also includes representations 

of two soft keys, a home key 204, and an info key 205. 
In this example, these soft keys are defined only for 
the card used to generate screen display 202. When the 
user presses a predetermined key sequence, the home key 

20 is highlighted to indicate the selection. In this 

embodiment, when the home key is selected, the user is 
returned to screen display 200. In another embodiment, 
the user could be returned, for example, to a home 
screen display that is displayed each time the user 

25 activates cellular telephone 100 for use on airnet 
network 150. 

The home key is associated with a pointer, that in 
one embodiment is a resource locator, and the card 
addressed by the pointer is displayed by the client 

3 0 process when the home key is selected by the user. 
Specifically, if the pointer is to a card in the 
current deck, the client process simply displays that 
card. If the pointer is to other than a card in the 
current deck, the client process in cellular 

35 telephone 100 retrieves the deck containing the card at 
the location identified by the pointer. The location 
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could be, for example, either a memory in cellular 
telephone 100, or a memory in computer 121. 

Similarly, when the user presses another 
predetermined key sequence, the info key is highlighted 
5 to indicate the selection. In this embodiment, when 
the info key is selected, a help screen is displayed 
for the user that describes the possible selections. 
The particular contents of the help screen are 
determined by the provider of the service. 
10 Specifically, a pointer is associated with the info key 
and when the info key is depressed by the user, the 
information stored at the location identified by the 
pointer is retrieved and interpreted by the client 
q process in cellular telephone 100. 

jfl 15 Returning to the menu in Figure 2C, since the user 

[g wants to determine the status of an order, the user 

*0 pushes the two key on the keypad of cellular 

jiTj telephone 100. In response to the key press, the 

M second choice in the menu is highlighted as shown in 

:\ 20 Figure 2C. In response to verification of the key 

iU press, e.g., the user presses a predetermined key 

!^ sequence, cellular telephone 100 transmits a check open 

[V, order request to computer 121, i.e, the client process 

13 transmits a message that includes a resource locator 

25 associated with the menu item selected by pressing the 
two key . 

In response to the check open order request, 
computer 121 transmits yet another card deck to 
cellular telephone 100. The client process in cellular 

30 telephone 100 interprets this deck, that is an entry 
card, and in turn generates a purchase order number 
entry screen display 206 (Fig. 2D) on display 
screen 105. Notice that screen display 206 has a 
previous soft key 207 and a fax soft key 208. Again, 

35 each of these soft keys has an associated pointer and 
the information stored at the location identified by 
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the pointer is retrieved and interpreted by the client 
process when the user selects the soft key. 

In this example, the user does not select a soft 
key, but rather the user enters the purchase order 
5 number as shown in Figure 2E using the keypad of 
cellular telephone 100. The user enters only the 
various numbers. The client process formats the number 
and inserts the dashes as shown in Figure 2E. 

After the purchase order is entered, the user 

10 presses a predetermined key sequence to indicate to the 
client process that entry of the purchase order number 
is complete. Notice that the user is entering data and 
not simply selecting a menu item.. The user is 
utilizing cellular telephone 100 as if cellular 

15 telephone 100 was a computer connected to network 120, 
but, as explained more completely below, cellular 
telephone 100 is similar to a standard digital data 
capable cellular telephone that communicates over data 
capable cellular telephone network 110. Specifically, 

20 cellular telephone 100 is not a combination of a 

computer module and a wireless communication module as 
in prior art attempts to create an intelligent 
telephone. 

In addition, the user enters data using only the 
2 5 standard cellular telephone keypad. Thus, cellular 
telephone 100 eliminates the need for a computer 
keyboard or for a sophisticated touch screen that 
recognizes motion of a pointing object. This is 
important to maintaining the size, weight, and power 
30 requirements of cellular telephone 100 similar to those 
of a voice-only cellular telephone. In one embodiment, 
to facilitate data entry, as explained more completely 
below, cellular telephone 100 includes a text 
prediction process that reduces the number of key 
35 strokes required to enter text data. In this 

embodiment, the text prediction process is turned on or 
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off for each entry card. 

In response to entry of the purchase order number, 
the client process transmits a request to server 
computer 121 for the particular purchase order. 
5 Specifically, the client process appends the entered 
data to a resource locator and transmits a message 
containing the resource locator to server computer 121. 
Server computer 121, in response to the message, 
retrieves the appropriate purchase order and transmits 
10 the purchase order as a card deck to the client process 
in cellular telephone 100 over airnet network 150. 

The client process interprets the card deck and 
generates a screen display 209 (Fig. 2F) . Initially, 
^ fax key 208 is not highlighted in screen display 209. 

15 Notice that screen display 209 includes multi- 

"0 display screen card indicator 2 03 to show the user that 

i2, th ^ purchase order screen contains more information 

lU that can be displayed at one time on display 

s ™* screen 105. 

\*k 20 After the user reviews the purchase order, the 

^ user presses the key sequence for" fax key 2 08 and in 

j= response, fax key 208 is highlighted as illustrated in 

y3 Figure 2F. 

^ In response to selection of fax key 208, the 

2 5 client process retrieves the card deck at the location 

identified by the pointer associated with fax key 208. 
If the location is on server computer 121, the client 
process transmits a message including a resource 
locator to server computer 121 and in response to the 

3 0 message, server computer 121 transmits back yet another 

card deck. If the location is on a server computer 
other than server computer 121, the client process 
transmits a message including a resource locator to 
that server computer and in response to the message, 
3 5 that server computer transmits back yet another card 
deck. If the location identified by the pointer is 
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within cellular telephone 100, the client process 
simply retrieves the deck. In either case, fax 
form 210 (Fig. 2G) , that is an entry card, is displayed 
on display screen 105 by cellular telephone 100. This 
example demonstrates the information accessed by the 
client process can be located in any number of 
locations. The resource locator associated with the 
fax key identifies the appropriate location. 

When fax form 210 is displayed, the user enters 
the facsimile machine telephone number at ABC Designs, 
as shown in Figure 2H, using the cellular telephone ~ 
keypad. In this embodiment, the telephone number is 
automatically formatted by the client process. After, 
the telephone number is entered, the client process 
appends the telephone number to a resource locator and 
transmits the information to server computer 121. 

When server computer 121 receives the information, 
server computer 121 executes a common gateway interface 
application (CGI) pointed to by the resource locator. 
The CGI application grabs the necessary information and 
transmits the information via e-mail to a fax gateway. 
The fax gateway, upon receipt of the e-mail, converts 
the information to a fax and sends the information to 
the specified telephone number. Thus, cellular 
telephone 10 0 requires neither a printer connection nor 
a print driver, but yet can print using the facsimile 
machine at ABC Designs. 

As illustrated in this example, cellular 
telephone 100 transmitted a request for a particular 
purchase order, and scheduled transmission of data 
responsive to the request to a local machine capable of 
printing the data. Thus, the processes of this 
invention, as described more completely below, in 
cellular telephone 100 in combination with data capable 
cellular telephone network 110 and server computer 121 
permit cellular telephone 100 to effectively utilize an 
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application on server computer 121 on network 120 even 
though cellular telephone 100 utilizes only a 
microcontroller found in telephone 100 and does not 
required a separate computer module as in the prior 
5 art . 

In addition, the client process using the 
information transmitted from server computer 121, i.e, 
the cards, generates a wide -variety of user interfaces 
as illustrated in Figures 2A to 2H. The particular 
10 configuration of the various user interfaces is defined 
by the cards transmitted in a card deck. Consequently, 
the user interface is not fixed to one particular 
format such as an E-mail type format, but rather the 
fS format is variable and can be redefined by each card 

*5 15 that is interpreted by the client process. Also, in 

"™ general, the user interface for one application on a 

kQ server computer is independent from the user interface 

]Tl for another application on that server computer. 

12 Specifically, the application accessed on server 

20 computer 121 generates the card deck and so in turn 
L defines each of the various use,r interfaces. Each user 

1U interface permits the user to identify a particular 

% selection. Each particular selection could result in 

m generation of a different user interface with different 

25 selections. Thus, the user interfaces are limited only 
by the applications accessible to the two-way data 
communication device. 

As shown below, a wide variety of applications can 
be provided on a server computer. Despite the 
30 robustness of the client module in interpreting a wide 
variety of application, typically, the client process 
is lightweight and thus requires only lightweight 
resources, e.g., 60 Kbytes of read-only memory (ROM) 
for the client module, 10 Kbytes of random access 
35 memory (RAM) , and less than one million instructions 
per second (MIPS) of processing power. Since the 
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client process needs only these lightweight resources 



^use existing resources in such a device and therefore 
does not add to the cost of the two-way data 
communication device such as data capable cellular 
telephone 100. 

In another embodiment, the user can configure 
cellular telephone 100 to access server computer 131 on 
corporate local area network 13 0. In response to the 
access by the user, computer 131 transmits a home card 
(not shown) to cellular telephone 100 which in turn 
generates a home screen display on display screen 105. 

When the user select's personal information on the 
home screen display or on a subsequent screen display 
associated with the home card, a message including a 
resource locator for a personal information deck is 
transmitted from, cellular telephone 100 to 
computer 131. In response to the message, computer 131 
transmits a card deck that includes a display card and 
a choice card to cellular ''telephone IQp . In these 
examples, the card deck is described as including one 
of three cards, a display card, a choice card, and an 
entry card. However, these examples are illustrative 
only, and are not intended to limit the invention to 
those particular embodiments of cards. In view of this 
disclosure, those skilled in the art will be able to 
form combinations of these types of cards and define 
other types of cards, if such cards are appropriate for 
the particular application. 

The client process in cellular telephone 100 
interprets the display card that includes image and 
text data and generates screen display 3 00 on display 
screen 105 (Fig. 3A) . Screen display 300 includes a 
home key 3 01, and an info key 3 02. When the user 
selects home key 301, the user is returned to the home 
screen. Info key 302 functions in a manner similar to 



in a two-way data communication device, the client can 
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that described above for info key 205. 

When the user presses a predetermined key, the 
client process interprets the choice card and a second 
screen display 3 04 (Fig. 3B) is driven on display 
5 screen 105, Screen display 304 is a menu of the 
personal information that is stored on server 
computer 131 for use by the user of cellular 
telephone 100. Multi-display screen card 
indicator 203, e.g., the hand with a finger pointing 
10 down, illustrates to the user that the list has 
additional items that appear on the next screen 
display. Screen display 3 04 also indicates the number 
of E-mail messages, faxes, and voice messages waiting 
for the user. 

15 The user scrolls the screen display line by line 

until screen display 305 is on display screen 105. 
Initially, the fourth item in the menu is not 
highlighted. In this example, the user presses the 
four key on the keypad of cellular telephone 100 to 

2 0 view the user's schedule. In response to the key 

press, the client module in cellular telephone 100 
transmits a message, including a resource locator 
associated with the menu item selected by pressing the 
four key, to server computer 131 using data capable 
25 cellular telephone network 110 and corporate local area 
network 13 0. 

In response to the message, server computer 131 
executes the application identified in the resource 
locator. Upon completion of the execution, server 

3 0 computer 131 transmits, over corporate local area 

network 13 0 and data capable cellular telephone 
network 110 to cellular telephone 100, a card deck that 
includes a choice card that describes the user's 
schedule for that day. 
3 5 In this embodiment, when server computer 131 

completes the transmission, server computer 131 has 
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completed the response to the message and has 
transmitted all necessary information to cellular 
telephone 100. Therefore, server computer 131 does not 
retain any state information concerning the transmitted 
5 information and so is referred to as a stateless server 
computer 131. In this embodiment, the client process 
can only request a card deck. However, as demonstrated 
herein, card decks and the two-way interactive data 
communication system of this invention provide the user 
10 with a new level of capability. 

When cellular telephone 100 receives the card 
deck, the client process in cellular telephone 100 
interprets the choice card and drives screen 
S3 display 306 (Fig. 3D) on display screen 105. 

l u 15 Initially, the first item in the menu of screen 

=fl display 306 is not highlighted. When the user 

^ depresses the one key on the keypad of cellular 

jjy telephone 100, cellular telephone 100 highlights the 

H first item in the menu/. Cellular telephone 100 

I\, 20 generates screen display 308 (Fig. 3E) upon the user 

!» subsequently depressing a predetermined key. Screen 

"if display 308 includes a schedule key 309, that when 

;; q selected returns the user to screen 

TO display 306 (Fig. 3D) . Screen display 308 also 

25 includes a more detailed description of the 10:00 a.m. 
meeting. 

While screen display 3 08 is active, if the user 
depresses a predetermined key, the user is presented 
with the options in screen display 310 (Fig. 3F) . 
30 Initially, item two in screen display 310 is not 
highlighted . 

In this example, the user depresses key two on the 
keypad of cellular telephone* 100 and so cellular 
telephone 100 sends a message including a resource 
35 locator to server computer 131 to send an E-mail 

message to Bill Smith confirming the meeting at 10:00 
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a.m. When server computer 131 executes the application 
addressed by the resource locator, an E-mail message is 
sent . 

In another example, the user of cellular 
5 telephone 100 connects to Internet service provider 
computer 141 on Internet 14 0 using data capable 
cellular telephone network 110. Upon connection of 
cellular telephone 100, service provider 141 transmits 
to cellular telephone 100 a card deck to generate 

10 Figures 4A to 4C. 

The client process in cellular telephone 100 
interprets the first card in the card deck from 
computer 141 and generates screen display 400 (Fig. 
4A) . When the user presses a predetermined key, 

15 cellular telephone 100 displays screen display 401 

(Fig. 4B) . Screen display 401 provides the user with a 
series of choices that group services alphabetically. 

When the user depresses the seven key on the 
keypad of cellular telephone 100, cellular 

20 telephone 100 displays a list of the services that have 
letters P, R, or S as the first letter in the service 
name. In this embodiment, screen displays 401 and 402 
are a single card, e.g., a single screen. Each of the 
various services associated with a key has an index and 

2 5 when a particular choice is made by the user, the 

choice defines an index. The client process then 
displays all of the services with the index that 
corresponds to the index defined by the user's choice. 
In screen display 402, the user is given a series 

3 0 of choices of services that are available to the user 

under tab seven. Initially, item three in screen 
display 4 02 is not highlighted. In this example, the 
user depresses the three key on the keypad of cellular 
telephone 100 to select the stock quotes and item three 
35 in screen display 402 is highlighted. 

In response to this selection, cellular 
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telephone 100 transmits a request for a stock quote, 
i.e, a message including a resource locator, over 
cellular telephone network 10 0 and internet 14 0 to 
service provider 141. In response to the request, 
5 service provider computer 141 executes the application 
addressed by the resource locator. The application 
retrieves a card deck that, in turn is transmitted to 
cellular telephone 100, The card deck includes a 
display card and an entry card. 
10 Upon receiving the card deck, the client process 

in cellular telephone 100 interprets the display card 
and generates screen display 403 (Fig. 4D) . When the 
user depresses a predetermined key, entry screen 
^ display 406 (Fig. 4E) is generated on display 

y3 15 screen 105 of cellular telephone 100. 

?^ Initially, the box with letters SUNW in screen 

«j5 display 406 is empty. The letters SUNW are entered in 

Jr: the box by the user to indicate the ticker symbol of 

LI the stock for .which the user wants information. After 

; ! 20 the user has entered the stock ticker symbol, the user 

L presses the predetermined key to indicate that the 

m entry is complete. -. I 

*|! In response to the entry by the user, the client 

m module appends the stock ticker symbol to the resource 

25 locator and transmits the resource locator to service 
provider computer 141 which, in turn, executes an 
application addressed by the resource locator to 
retrieve the latest stock market information for the 
stock ticker symbol. Service provider 141 uses the 
3 0 retrieved information to generate a card deck that 

contains the information and then transmits the card 
deck to cellular telephone 100. 

The client process in cellular telephone 100 
interprets the first card in the deck and generates 
35 screen display 409 (Fig. 4F) . For convenience, the 

Figures 4F to 41 are grouped together and separated by 
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a dotted line. However, at any given time, in this 
embodiment, display screen 105 can display any four 
adjacent lines and so the grouping of lines in Figures 
4F to 41 is for convenience only to demonstrate the 
5 level of information that can be retrieved and 

displayed by the client process. The use of a four 
line display screen is illustrative only. The client 
process of this invention can work with any size 
display screen, even a one line display screen. 

10 However, a multi-line display screen is preferred. 

In the Figures discussed above, the display screen 
is a pixel display and so can display images. In 
another embodiment, the display screen only displays 
text and is smaller in size. For such an embodiment, 

15 the various entries are abbreviated and only text is 
displayed, but the general operation is identical to 
that just described. Also, the various computer 
networks can be interlinked so that a user with access 
to one computer network can obtain information on 

2 0 another computer network. Moreover, the embodiments 

described above are merely illustrative. One important 
aspect of this invention is that cellular telephone 100 
can interact with any type' of server application that 
is configured to communicate with and interact with the 
25 client process in cellular telephone 100. Thus, the 
user is no longer limited to only a few services 
offered by a telephone network provider. 

In Figure 1, the cellular telephone user must 
address, i.e., connect to, each computer of interest to 

3 0 access the different services. Consequently, each 

computer requires the information necessary to 
communicate with cellular telephone 100. In another 
embodiment, not illustrated, cellular telephone 100 
contacts a single central computer over data capable 
35 cellular telephone network 110. This computer is 

connected to each of the other networks illustrated in 
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Figure 1. Consequently, the user of cellular 
telephone 100 sends a message including a resource 
locator to the central computer, the central computer 
processes the message and retrieves the information 
5 addressed by the resource locator from the appropriate 
network shown in Figure 1 . After the requested 
information is retrieved, the central computer 
generates a card deck and transmits the card deck to 
cellular telephone 100. In this embodiment, only one 

10 computer must be configured to communicate with 

cellular telephone 100. However, that same computer 
must be configured to communicate with all other 
computer networks that are of interest to the user of 
cellular telephone 100. 

15 Hence, according to the principles of this 

invention, the client process on a two-way data 
communication device can initiate an interaction with a 
particular server computer. The server computer 
transmits (i) information to the client, process to 

20 generate a user interface, and (ii) a resource locator 
for each possible selection by the user from the user 
interface . The resource locators can address 
applications on the server computer, applications on 
over server computers, or an application on the server 

25 computer that in turn accesses other server computers. 
Consequently, the user of a two-way data communication 
device is limited only by the applications provided on 
the server computers. 



3 0 updated capabilities by modifying the applications on 

the server computers. There is no requirement that the 
client process be changed for a new or updated 
application. The client process must only interpret 
the information received from an application and 

35 transmit a message for additional information. These 
operations are unaffected by a new or updated 



Further, the user can be provided new and/or 
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application. Consequently, as noted above, this 
invention does not require distribution of application 
updates or new applications to the end user of the two- 
way data communication device. 
5 Figure 5 is an illustration of another embodiment 

of airnet network 150. In this embodiment, the 
messages from a two-way data communication device, 
e.g., devices 100, 101, and 102 are directed to an 
airnet network translator 500. Airnet network 

10 translator 500 and a particular two-way data 
communication device, e.g., any one of 
devices 100, 101, and 102 communicate using the 
protocol for point-to-point communication on the 
particular network linking airnet network translator 

15 500 and that two-way data communication device. For 

example, if data capable cellular telephone network 110 
is a cellular digital packet data network, either the 
transmission control protocol (TCP) or the user 
datagram protocol (UDP) if can be used. 

20 Airnet network translator 500 transfers data 

between the two-way data communication device and the 
selected computer network after translator 50 0 
validates the communication path, -as explained more 
completely below, and encrypts the message transferred 

25 to the computer network if necessary. In addition, 

airnet network translator 500 collects transaction and 
billing information concerning the communication 
between the two-way data communication device and the 
designated computer network. Specifically, airnet 

30 network translator 500 provides access control for 

paying services and a logging mechanism for billing. 
Airnet network translator 500 can also provide a 
directory service to users . 

Figure 6 is a block diagram of a typical GSM 

35 digital cellular telephone. Each of the hardware 

components in cellular telephone 600 is known to those 
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skilled in the art and so the hardware components are 
not described in detail herein. The compiled and 
linked processes of this invention are stored in 
ROM 601 as a client module 602 and support modules 603. 
5 Upon activation of a predetermined key sequence 

utilizing the keypad, physical layer processor 610, 
that is sometimes referred to herein as a 
microcontroller, initiates a client process using 
client module 602 in ROM 601. 

10 In this embodiment, client module 602 includes a 

plurality of manager modules, as explained more 
completely below. The particular manager modules 
utilized is determined by the characteristics of the 
particular cellular telephone 100 in which client 

15 module 602 is implemented. Client module 602 must 

include manager modules to interface with modules that 
control the particular hardware in cellular 
telephone 100, a manager module to interface with the 
particular cellular telephone network protocol used by 

20 cellular telephone 100, and a manager module to 

interpret the card decks received. Therefore, the 
particular manager modules described herein are only 
illustrative of th^ principles of this invention and 
are not intended to limit the invention to the specific 

25 modules described more completely below. 

In this embodiment, the client process controls 
the operations of a plurality of cellular telephone 
dependent support processes that are stored in ROM 6 01 
such as a display module, a keypad module, and a 

3 0 network and terminal control module, that were referred 
to above collectively as support modules 603. The 
combination of the client process, display process, 
keypad process, and network and terminal control 
process are considered foreground tasks by the 

35 microkernel in cellular telephone 600. Also, herein 

module and process are used interchangeably, but those 
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skilled in the art will appreciate that the module is 
the computer software as stored in a memory, 
preferably, a ROM, of cellular telephone 600 and the 
corresponding process is the execution of the module by 
5 the microcontroller in c e 1 1 u 1 ar te 1 ephone 600. Again, 
note that this invention does not require a separate 
processor and instead can utilize the processing power 
that already exists in cellular telephone 600, because 
as described above, the client process of this 

10 invention is so lightweight. 

The user interface for cellular telephone 600 
determines the version of the user interface manager 
module that is stored in ROM 601. In one embodiment, 
the parameters used to define the user interface level 

15 are the display resolution, the pixel access of the 

display, and the support of soft keys. One definition 
of the user interface levels is given in Table 1. 




TABLE 1 

2 0 USER INTERFACE LEVEL DEFINITIONS 

Level 1" Text only; 1 or more lines; 12 

to 15 characters per line; and no 
soft keys . 

Level 2 Text only; 4 or more lines; 20 to 

25 25 characters per line; and soft 

keys . 

Level 3 Pixel access; 150 by 75 pixels or 

larger; and soft keys. 



3 0 The user interface manager module presents data to 

the display module which in turn drives display 
screen 605; and captures data entered by the user on 
display screen 605. In response to this information, 
the client process prepares a message for transmission 

3 5 by a network manager module. 

To more completely explain the operations 
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performed over airnet network 150, Figure 7 is a block 
diagram that illustrates the various components in one 
embodiment of this invention of cellular telephone 700. 
Those skilled in the art will appreciate that cellular 
5 telephone 700 includes circuitry and software similar 
to that illustrated in cellular telephone 600 for voice 
and data operations supported by cellular telephone 700 
in addition to the modules for operation on airnet 
network 750. Similarly, server computer 743 includes 

10 other software and hardware that is known to those 
skilled in the art and so is not illustrated in 
Figure 7 for clarity. 

In this embodiment, client module 702 in digital 
cellular telephone 700, that is executing on the 

15 microcontroller of telephone 700, communicates with 

server computer 743 over cellular digital packet data 
(CDPD) network 710. Cellular digital packet data 
network 710 is used ' to illustrate one embodiment of 
this invention on one two-way data communication 

20 network. The principles of this invention can be used 
with a wide variety of two-way data communication 
networks. For example other two-way data communication 
networks for ^cellular telephones that may be used 
include TDMA, CDMA, and GSM circuit switched data 

25 networks; and the AMPS analog cellular network with a 
modem. Similarly, for two-way pagers, two-way data 
communication networks include PACT, or other priority 
two-way paging networks with data transport capability. 
Prior to considering the operation of this 

3 0 configuration of airnet network 750 in more detail, 
another aspect of this invention is required. 
Specifically, a technique is required for conveying 
instructions from digital cellular telephone 700 to a 
server application on server computer 743, and 

3 5 conversely. 

A telephone interaction description 
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language (PIDL) is defined for use by service 
developers- A terminal interaction language (TIL) is a 
distillation of the telephone interaction description 
language and describes the same interaction to digital 
5 cellular telephone 700 as the telephone interaction 
description language describes to computer 743. 

With the exceptions described more completely 
below, a process in the terminal interaction language 
is a compressed version of the same process written in 

10 the telephone interaction description language. The 
terminal interaction language allows easy parsing on 
the two-way data communication device, which in turn 
makes the client smaller than a client for the 
telephone interaction description language that is 

15 readable by humans, but is not optimized for parsing by 
a machine . 

The compression from the telephone interaction 
description language to the terminal interaction 
description language is done typically at run time 

2 0 because some cards are computed cards and so cannot be 

precompiled. A wide variety of techniques can be used 
to convert the telephone interaction description 
language to terminal interaction language. The 
important aspect is that, if bandwidth across the 
25 cellular telephone network is limited, a compressed 

form of the telephone interaction description language 
is used. 

Preferably, each data type is compressed to 
facilitate optimal transfer over the two-way data 

3 0 communication network. For example, the verbs in the 

telephone interaction description language are 
compressed using a binary tokenization . Graphics are 
compressed using run length limited compression and 
text is compressed using any one of the well-known 
35 techniques for text compression. While compression of 
the telephone interaction description language is not 

-43- 




L:\DMS\7 574\M-342 3 U\0135£^ 



required to implement this invention, compression makes 
the invention more efficient by utilizing the bandwidth 
of the network more effectively. 

Instructions in the telephone interaction 
5 description language and in the terminal interaction 

language are grouped into a deck and a card. Each deck 
includes one or more cards . A card includes the 
information, i.e., a set of telephone interaction 
description language, required to generate a screen. 

10 As indicated above, a screen can be larger than the 

number of lines in a display screen. Other equivalent 
terms for a card include a page and an atomic 
interaction. Thus, a card deck is simply a group of 
screens . The number of cards in a card deck is 

15 selected to facilitate efficient use of the resources 
in the two-way data communication device and in the 
airnet network. 

For simplicity, in this embodiment > each card is a 
single operation. Herein, an operation is defined as a 

20 related set of actions such that the user does not 
encounter an unanticipated delay in moving from one 
action to the next, i.e,""the user does not have to wait 
for client module 702 to retrieve another card deck 
from computer 743. Also, a deck may include 

25 definitions of soft keys that stay in force while the 
deck is active, i.e, being executed by the cellular 
telephone microcontroller. 

Computer 743 may contain stored static telephone 
interaction description language decks. Computer 743 

3 0 also generates telephone interaction description 

language decks in response to data from, or choices 
made by, the user of cellular telephone 700. 

In the embodiment shown in Figure 7, computer 74 3 
converts a telephone interaction description language 

3 5 deck to a terminal interaction language deck, that in 
turn is transmitted to cellular telephone 700. The 
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terminal interaction language is designed so that decks 
can be stored unaltered in memory 716 of cellular 
telephone 700 and referenced directly with little or no 
parsing. While telephone interaction description 
5 language decks on computer 743 may contain references 
to images, a terminal interaction language deck 
contains the images at the end of the deck. Thus, if a 
particular two-way data communication device does not 
support display of images, the images are easily 

10 stripped from the terminal interaction language deck 

before the deck is transmitted to that particular two- 
way data communication device. 

As indicated above, each interaction with the user 
of cellular telephone 700 is described by a deck or a 

15 series of decks. Logically, the user retrieves a 
terminal interaction language deck stored in a 
memory 716 of cellular telephone 700 after receipt from 
computer 743 over CDPD network 710. The user reviews 
the information displayed by cards in the deck and 

20 makes choices and/or enters requested information and 
then requests another deck, as described above with 
respect to Figures 2A to 2H, for example. 

When the user receives a deck, the first card of 
information is displayed on display screen 705. 

2 5 Typically, as shown above, the first ^ard is text, an 

image, or a combination of an image and text. After 
the user has reviewed the first card, the user hits a 
NEXT key to view the next card in the deck. Similarly, 
a user can return to a previous card in the deck by 

3 0 using a PREV key. Thus, using the NEXT and PREV keys, 

the user can navigate back and forth through the deck. 
Within a card, the user uses a scroll key or keys to 
move the portion of the card displayed up and down. 
This description of a particular method used to 
3 5 navigate through a deck and within a card is not 

intended to limit the invention to this particular 
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method. In view of this disclosure, those skilled in 
the art will be able to use a wide variety of ways to 
navigate through a deck and within a card. 

Cards, in this embodiment, are one of three types, 
5 , a display card, a choice card, and an entry card. 

Independent of the type of card, the card can contain 
text and images. In addition, the invention is not 
limited to these three particular types of cards. The 
definition of the three particular types of cards is 

10 used to facilitate a description of the invention and 
to assist the developer's in organizing applications. 

A display card gives information to the user to 
read. The display content can include any one of, or 
any combination of text, an image, and a soft key. The 

15 soft key is in effect only while the display card is 
active. 

A choice card displays a list of choices for the 

user. The choices are automatically presented in a 

.• re- 
format specxfied on the choice card. See Appendix I, 

2 0 which is a part of the present disclosure and is 

incorporated herein by reference in i4ts entirety. As 

explained above, the user makes a choice by depressing 

the key corresponding 1 / to the choice. 

An entry card is used to obtain input data from 

2 5 the user. An entry card displays one or more entry 

lines. Typically, each entry line includes a display 
followed by an entry line. The entry line, in this 
embodiment, can be for either numeric or text data. 

In this embodiment, choice and entry cards prevent 

3 0 the user from moving to the next card until the user 

has entered the requested information. When the user 
reaches the last card in a deck and hits the NEXT key, 
a request for a new deck is initiated. The deck 
requested is determined by either the deck that the 
3 5 user has completed, or by the choices made by the user. 
Also, when the deck is completed, the choices and/or 
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data entered by the user typically are transmitted 
along with the request for the new deck to 
computer 743 . 

Appendix I is one embodiment of a syntax for the 
5 telephone interaction description language and the 

terminal interaction language of this invention. In 
one embodiment, the telephone interaction description 
language is described using a subset of the standard 
generalized markup language. Only a subset of the 
10 standard generalized markup language is utilized so 

that telephone interaction description language parsers 
also can be written easily using simple tools like lex 
and yacc . 



15 cellular telephone 700 includes a display module 712, a 
keyboard module 711, a client module 702, and a UDP 
interface module 714. In this embodiment, module 702 
is stored in a non-volatile memory (not shown) of 
telephone 700 and is executed by the microcontroller 

20 (not shown) in telephone 700. Modules 711, 712, and 
714 operate under the control of client module 702. 

Client module 702 includes instructions that 
direct the microcontroller in cellular telephone 700 to 
perform the operations described more completely below 

2 5 with respect to Figures 8A to 8D. The operations 

include sending uniform resource locator (URL) requests 
to HyperText Transfer Protocol (HTTP) server 749, 
parsing and displaying a TIL deck or decks returned by 
HTTP server 74 9, and generating new URLs based on the 
30 user's key presses. For a description of HTTP server 
software and platforms that can run the HTTP server 
software, see, for example, Ian S. Graham, The HTML 
Sourcebook , John Wiley & Sons, Inc., New York, 
Chapt . 8, (1995), which is incorporated herein by 

3 5 reference. 



Returning to operation over airnet network 750, 



User datagram protocol (UDP) interface module 714 
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couples CDPD network 710 to client module 702, and 
allows client module 702 to communicate using UDP over 
CDPD network 710. The user datagram protocol is well 
known to those skilled in the art and is documented 
5 extensively. UDP interface module 714 supports 

transmission of simple stand-alone messages between the 
connection partners. 

Display module 712 is a display driver that 
couples client module 702 to display screen 705 and so 

10 allows client module 702 to specify the information 
presented on display screen 705. The user interface 
manager module within client module 702 converts the 
display information in a card to instructions for 
display module 704 which in turn provides signals that 

15 drive the hardware that controls the operation of 
display screen 705. For example, if the TIL deck 
includes an image, the user interface manager module 
determines whether the active card calls for display of 
the image. If the active card directs the user 

2 0 interface manager module to display the image, the user 

interface manager module passes the image in memory 716 
to display module 712, which in turn ^displays the image 
on display screen 705. 

Keyboard module 70 5 couples keypad 715 to client 
25 module 702, and stores data representing keys pressed 
by the user on physical keypad 715 in memory 716 . 
Keyboard module 705 notifies client module 702 when the 
user has pressed a key. 

When client module 702 is notified of a key press, 

3 0 the user interface manager module within client 

module 702 passes information about the key press to 
display module 712 that in turn displays the 
appropriate character on display screen 705, if an 
entry card is active. If the user interface manager 
3 5 module determines that a choice card is active, and the 
key press corresponds to one of the choices, the user 
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interface manager module sends instructions to display 
module 712 that result in the choice being identified 
for the user, e.g., highlighted as described above. 

In addition to HTTP server 74 9, host computer 743 
5 includes a UDP interface module 74 8, CGI programs 761 
stored in a memory 755 of host computer 743, and TIL 
decks 760 stored in memory 755. 

HTTP server 74 9 uses UDP interface module 748 to 
send data to and receive data from CDPD network 710 . 
10 TIL decks 760 are TIL decks that can be accessed by 
HTTP server 749. Static files containing PIDL decks 
are converted to TIL decks only once on HTTP 
server 749. CGI programs 761 are common gateway 
= ™ interface programs that produce PIDL decks that are 

m 15 used by HTTP server 74 9 to produce TIL decks that in 

turn are transmitted via UDP interface modules 748 and 
1^ 714 and cellular telephone network 710 to client 

module 702. In this embodiment, the services available 
I over airnet network 750 are applications accessible by 

H 2 0 HTTP server 74 9 on Internet 14 0 for which a service 

5^ developer has written a PIDL deck, or a CGI script that 

s j£ in turn generates a PIDL deck, and is stored on 

computer 743. 

m The architecture in Figure 7 demonstrates some 

25 important aspects of this invention. First, the 

applications, the PIDL decks and CGI scripts in this 
embodiment, are ^independent of the particular two-way 
data communication network. For HTTP server 74 9 to 
communicate over a different two-way data communication 
3 0 network that does not support UDP, only UDP interface 
module 74 8 must be changed. The applications are 
unaffected by such a change. 

Second, the applications on HTTP server 74 9 are 
independent of the two-way data communication device 
3 5 with which HTTP server 74 9 is interacting. An 

application on HTTP server 74 9 can communicate with any 
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two-way data communication device that includes the 
appropriate client and a module to transmit and receive 
data over the two-way data communication network. 
These two facts mean that .an investment in developing 
5 an application is insulated from either advances in 

two-way data communication devices, or advances in two- 
way data communication network technology . 

Figures 8A to 8D are a process flow diagram for 
one embodiment of this invention. Initially, when the 
10 user initiates communication over airnet network 750, 
client module 702 initializes a work space in 
memory 716; pf cellular telephone 700 and then, in get 
home URL process 801, stores a URL in the work space. 
^ According to the principles of this invention, in one 

g*4 15 embodiment, each cellular telephone that utilizes the 

^ airnet network has a home URL stored in a non- volatile 

{1 memory that is used to retrieve a home card deck for 

iU the cellular telephone. In another embodiment, the 

cellular telephone obtains the home URL from 
i*& 20 server 74 9. Thus, in get home URL process 801, client 

jr! module 702 obtains the home URL. Herein, a URL is an 

,p example of a specific embodiment of a resource locator. 

*B For example, in get home URL process 801, client 

TO module 702 obtains a home URL, such as 

25 

http : //www. libris . com/airnet/home . cgi 

and stores the home URL in the work space. The portion 
of the home URL, http : /www. libris . com, identifies a 

30 particular HTTP server, i.e, server 749, on the world- 
wide web. The portion of the URL, /airnet /home . cgi , 
specifies a particular common gateway interface program 
within CGI programs 761. The use of a URL pointing to 
a server on the world-wide web is illustrative only is 

35 not intended to limit the invention to applications on 
the world-wide web. In general, cellular telephone 700 
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obtains an identifier, i.e, a resource locator, of a 
home application on a home server that is executed by 
the server when the cellular telephone initially 
becomes active on airnet network 750, and stores the 
resource locator in the work space. 

Next in create HTTP request process 802, client 
module 7 02 converts the URL in the work space to a HTTP 
request- For example, for the above URL, create HTTP 
request process 8 02 generates a method field, such as 

GET /airnet/home . cgi HTTP/l.O 

The GET method is part of HTTP. Thus, the format for 
the GET method is known to those skilled in the art . 
Also, this particular form of the method is used 
because a specific server connection is established by 
cellular telephone 700 and so identification of the 
server is unnecessary. Nevertheless,* brief ly, this 
command instructs server 74 9 to execute application 
home. cgi and execution of application home . cgi in turn 
results in generation of a home deck and a subsequent 
transmission of the home deck to cellular 
telephone 700. HTTP/l.O specifies the HTTP version 
used by client module 702 in cellular telephone 700. 

In addition to the method field, client module 702 
in process 8 02 could also generate appropriate HTTP 
request fields to pass .inf ormation to server 749 about 
the capabilities of client module 702. The request 
fields can include information such as lists of the 
MIME content- types acceptable to the client; lists of 
data encoding types acceptable to the client; user 
authentication and encryption scheme information for 
the server; the length in bytes of the message being 
sent to the server; and the Internet mail address of 
the user accessing the server. This list of 
information is illustrative only and is not intended to 
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limit the invention to the particular request fields 
described herein. Any request field defined by HTTP 
can be utilized by client module 702. However, in this 
embodiment, the defaults are utilized and so no HTTP 
5 request fields are generated. 

Typical HTTP methods that can be generated in HTTP 
request process 802 are a GET method for requesting 
either a TIL deck from server 749, or execution of a 
common gateway interface program on server 74 9; and a 

10 GET method request to a common gateway interface 

program with data, e.g., a query string appended to the 
URL. In either case, a URL is transmitted to 
server 749 within the particular message. After create 
HTTP request process 802, is complete, client process 

15 transfers to transmit . request process 804. 

However, if the transmission control protocol is 
used instead of UDP, client module 702 would access a 
TCP module in establish "server connection process 8 03 
that replaced UDP module .714 . Since, in this 

20 embodiment, UDP is used, establish connection 

process 8 03 is enclosed by a dashed line in Figure 8A 
to indicate that this process is unnecessary when using 
UDP. 

In establish server connection process 803, a 
25 virtual connection would be made over CDPD network 710 
between TCP interface module 714 and a TCP interface 
module in HTTP server 74 9 so that data could be 
transmitted between cellular telephone 700 and 
computer 743 using TCP, e.g., buffers to support data 
3 0 exchange are defined. The establishment of a TCP 
connection is well-known and so is not described 
further. 

In Figure 8A, a dashed line connects establish 
server connection process 803 with establish client 
35 connection process 860, that is also dashed, that is 

performed by HTTP server 74 9. This indicates that both 
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client module 702 and server 74 9 are required to 
complete process 803. 

When the TCP virtual connection is established, 
client module 702 transfers processing from establish 
5 server connection process 803 to transmit request 
process 804. Similarly, server 749 transfers to 
request received check 861, in which server 749 waits 
until a request is received. Establish client 
connection process 860 is not needed for UDP and so 
10 HTTP server 74 9 initiates processing in request 

received check process 861. Process 860 is enclosed 
within a dashed line box to indicate that the process 
is used only for TCP. 

In transmit request process 804, the HTTP request 
m 15 is sent from the work area in telephone 700 to HTTP 

^ server 749. Again, a dashed line connects process 804 

l2 of client module 702 to request received check 861 that 

is performed by HTTP server 74 9 to indicate that the 
I check is dependent upon information from client 

H 20 module 702. Wheri the transmission of the request is 

.TJ complete, client, module 702 transfers to response 

S E* received check 806. 

;^ Upon receipt and storage of the HTTP request, 

m request received check 861 transfers to service request 

25 process 862 in which HTTP server 749 initiates service 
of the received request. In service request 
process 862, if the HTTP request only seeks transfer of 
a static deck, HTTP server 749 retrieves the requested 
static deck from TIL decks 760. Conversely, if the 
3 0 request requires server 74 9 to obtain data from the 
Internet or to append data to a particular file, 
server 74 9 launches the common gateway interface 
application addressed in the request, and passes the 
data in the HTTP request to this application for 
35 further processing. 

For example, if the user of cellular telephone 700 
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requested a fax as in Figure 2F , the HTTP request 
identifies a common gateway interface application in 
CGI programs 761 that accepts as input data the 
telephone number and grabs the information to be faxed. 
5 The CGI application generates an e-mail transmission to 
the fax gateway. Similarly, for a stock quote, server 
749, in response to the HTTP request, launches a common 
gateway interface application that sends out a stock 
query over Internet 140 to a stock quote service 

10 provider using the ticker tape symbol passed as input 
data by server 74 9 to the common gateway interface 
application. When the response to the stock query is 
received, the common gateway interface application 
builds a PIDL deck that includes the data in the 

15 response to the stock query. 

Upon completion of servicing the request, 
HTTP server 74 9 converts the PIDL deck to a TIL deck 
and returns the TIL deck to client module 702 using UDP 
in transfer response process 863, that is connected by 

20 a dotted line to response received check 806 in client 
module 702. As the TIL deck is transferred, client 
module 702 stores the deck in memory 716. 

After the TIL deck is transferred, HTTP server 74 9 
closes the process for responding to the message from 

25 cellular telephone 700. All the information needed by 
client module 702 to generate a user interface on 
display screen 705 and for responding to any selection 
or data entry presented in the user interface is 
included in the TIL deck. Consequently, client 

3 0 module 702 only has to interpret the TIL deck and 

interpret the user input to transmit the next message 
to HTTP server 74 9. The state for the HTTP server is 
defined in the next message. Consequently, HTTP server 
749 is stateless because HTTP server 749 does not 

35 retain state information concerning a response to a 
message after the message is transmitted. 
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However, in another embodiment (not shown) , a 
server could retain state information concerning each 
interaction with a client module. For example, if the 
server transmitted a choice card to the client module, 
5 the server would retain state information indicating 
that a choice was pending from the client module. In 
this embodiment, when the user makes a choice, e.g., 
depresses key two to indicate choice two, the choice is 
transmitted to the server which in turn accesses the 

10 URL associated with choice two. If this URL addresses 
another application, the server executes that 
application. Thus, in this embodiment, the server 
retains state information concerning each interaction 
with a client module. In view of this disclosure, 

15 those skilled in the art can implement the principles 

of this invention utilizing a server that retains state 
information when such a client/server combination is 
advantageous . / 

Returning to the present embodiment, when the TIL 

20 deck is received, client module 702 leaves response 
received check process 806 and transfers to process 
first card 808. However, if TCP is used instead of 
UDP, client module 702 upon leaving check 8 06 would 
close the virtual TCP connection in transmission 

25 completed process 807. Upon closing the virtual TCP 

connection, processing would transfer to process first 
card 808. Again, transmission complete process 807 is 
enclosed within a dashed line box to indicate that 
process 807 is used only with TCP. 

30 In process first card 808, client module 702 

parses the TIL deck and interprets the first card. 
Processing transfers from process first card 808 to 
generate display process 809. 

In generate display process 809, client module 702 

3 5 passes the data to be displayed in the first card to 

display module 712. Display module 712, in response to 
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the data, drives the text and images in the data on 
display screen 705. Generate display process 809 
transfers processing to key press check 820 through 
node 813. In Figures 8A to 8D, any circular node with 
5 the same alphanumeric character and reference numeral 
is the same node. The circular nodes are used to 
establish connections between the various processes in 
the method of Figures 8A to 8D without cluttering the 
figures with a number of connection lines. 

10 Client module 702 waits in key press check 820 for 

the user to press a key on keypad 715 of cellular 
telephone ,700. In this embodiment, cellular 
telephone 700 is assumed to have the capability to 
support two soft keys, a scroll-up key, a scroll-down 

15 key, a previous key, a next key, and keys zero to 9 
that are configured in the standard telephone keypad 
configuration. In view of the following disclosure, if 
one or more of these keys are not present, one of skill 
in the art can alter, the method for the particular 

20 configuration of the cellular telephone keypad, or 

other two-way data communication device keypad. For 
example, if the cellular telephone included a home key, 
the key press processing described more completely 
below would include a check that detected when the home 

2 5 key was pressed and would in turn transfer to get home 
URL process 801. 

Briefly, the processes in Figures 8B to 8C, 
identify the key pressed by the user, identify the 
action required, and then transfer to a process that 

30 implements the action required. Specifically, when a 
key on the keypad is pressed, keypad module 711 stores 
an identifier for the key in work memory 716 and 
notifies client module 702 of the key press. Upon 
receipt of the notification from keypad module 711, 

35 client module 702 reads the storage location in work 
memory 716 to determine the key pressed and transfers 
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processing from key press check 820 to scroll key- 
check 821. 

In scroll key check 821, client module 702 
determines whether the user pressed either of the 
5 scroll keys. If a scroll key was pressed, processing 
transfers to adjust display process 822 and otherwise 
to display card check 823 . 

In adjust display process 822, client module 702 
determines which of the scroll -up or scroll -down keys 

10 was pressed. Client module 702 then sends information 
to display module 712 so that the current display is 
either scrolled-up one line or scrolled- down one line. 
If the scroll key would move the display beyond a 
boundary of the current card, the scroll key press is 

15 ignored in adjust display process 822. 

In response to the information from client 
module 702, display module 712 adjusts the screen 
display on display screen 705. Client module 702 
transfers processing from adjust display process 822 to 

20 key press check 820 through node 813. 

If a scroll key was not pressed, processing is 
passed through scroll key check 821 to display card 
check 823. Client module 702 takes action that depends 
on the particular type of card that is currently being 

25 displayed on display screen 705. If the current card 
is a display card/ client module 702 passes through 
display card check 823 to soft key check 828, and 
otherwise transfers to choice card check 824. 

Assuming for the moment that the current card is 

30 not a display card, choice card check 824 determines 
whether the current card is a choice card. If the 
current card is a choice card, client module 702 passes 
through choice card check 824 to choice key check 826, 
and otherwise transfers to data key check 826. 

3 5 Assuming for the moment that the current card is 

neither a display card nor a choice card, the current 
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card must be an entry card, because in this embodiment 
only three card types are defined. Thus, client 
module 702 does not check for an entry card. Rather, 
data key check 82 6 determines whether a valid data key 
5 was pressed. In this embodiment, the data keys are 
keys zero to nine on the key pad, and the # key. In 
other embodiments, other combinations of keys could be 
defined as data keys. If the pressed key was one of 
the data keys, data key check 826 transfers to process 
10 data entry 827 and otherwise transfers to soft key 
check 82 8. 

In process data entry 827, client module 702 knows 
whether the predictive text entry process is turned-on, 
because one of the parameters on the entry card 

15 specifies whether to use the predictive text entry 
process, as described in Appendix I, whiph is 
incorporated herein by reference in its„, entirety . 

If the predictive text entry process is not 
turned-on, client module 702 in process data entry 827 

20 enters the pressed key value in a text entry buffer in 
work memory 716 at the appropriate location. Also, 
client module 702 sends information to display 
module 712 so' the value of the pressed key is displayed 
in the appropriate location on display screen 705 by 

25 display module 712. 

If the predictive text entry process is turned-on, 
client module 702 uses the novel predictive text entry 
process in process data entry 827, as described more 
completely below with respect to Figures 9, 10A to 10T, 

3 0 and 11, to determine the letter to select from the set 
of letters associated with the pressed key. After the 
predictive text entry process determines the 
appropriate letter, a value representing the letter is 
stored at the appropriate location in the text buffer 

35 in work memory 716. Also, client module 702 sends 

information to display module 712 so that the letter is 
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displayed in the appropriate location on display 
screen 705. Upon completion of process data entry 827, 
client module 702 transfers processing through node 813 
to key press check 820. 

The previous description assumed that the current 
card was an entry card, but if the current card is a 
choice card, choice card check 824 transferred to 
choice key check 826. In generate display process 804 
for the choice card, each of the choices are labeled 
according to information on the choice card and some or 
all of the choices are displayed on display screen 705. 
Thus, choice key check 82 6 determines whether the 
pressed key corresponds to one of the choices. If the 
pressed key is one of the choices, client module 702, 
in one embodiment, sends information to display 
module 712 to indicate the selected choice. Client 
module 702 also transfers from choice key check 82 6 
through node 831 to store identifier process 850 
(Fig. 8D) , that is described more completely below. 
Conversely, if the pressed key is not one of the 
choices, choice key check 826 transfers to soft key 
check 828. 

Soft keys can be specified both for a deck as a 
whole and per card, i.e., a physical key on the keypad 
is specified as a soft key as described more completely 
in Appendix I. Each soft key specification includes an 
identifier that defines the action to be taken when the 
soft key is pressed. 

When a soft key is specified for a deck, the soft 
key remains in effect for the entire deck. However, 
when a soft key is specified for a card, the card soft 
key specification temporarily overrides the 
corresponding deck soft key specification, i.e., the 
deck soft key specification for the same physical key 
as the card soft key specification, while the card is 
visible, i.e., displayed on display screen 705. This 
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override is done independently for the two soft keys. 
Thus, soft key check 828 transfers processing to first 
soft key check 82 9 if the key pressed is one of the two 
possible physical soft keys. Conversely, soft key 
5 check 828 transfers processing to next key check 84 0 

(Fig. 8C) , if neither of the two possible physical soft 
keys is pressed by the user. 

In first soft key check 829, client module 702 
determines whether the pressed key corresponds to the 
10 first soft key. If the pressed key is the first soft 
key, check 829 passes the active identifier for the 
first soft key to store identifier process 850 through 
node 831. Conversely, if the pressed key is not the 

" first soft key, processing transfers from check 829 to 

jU ; 15 second soft key check 830. 

^ If the pressed key is the second soft key, 

;Z& check 830 passes the. active identifier for the second 

soft key to store identifier process' 850 through 
* node 831. Conversely, if the pressed key is not the 

H : 20 second soft key, e.g., a physical key that can be 

^ defined as a soft key/ was pressed but neither the 

s p current deck nor the current card defines a soft key 

for that physical key, processing transfers from 
check 830 to key press check 820 through node 813. 
25 When pressing transfers to next key check 840, 

client module 702 determines whether the pressed key 
was the next key. If the next key was pressed, 
processing transfers to display card check 841 and 
otherwise to previous key check 846. 
30 If a display card is the current card, the next 

key is used to move to another card in a deck, or 
alternatively to another deck. Thus, display card 
check 841 transfers processing to last card check 842 
when a display card is the current card, and otherwise 
35 to entry card check 843. 

Last card check 842 determines whether the current 
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card is the last card in the deck. If the current 
display card is not the last card in the deck, last 
card check 842 transfers processing to read next card 
process 845, which in turn reads the next card in the 
5 deck and transfers through node 812 to generate display- 
process 809. 

If the current display card is the last card in 
the deck, the deck includes an identifier that 
specifies the location to transfer to from the last 

10 card. This identifier can be a URL to another deck, to 
a common gateway interface program, or an address for a 
card within the current deck, for example. Thus, last 
card check 842 transfers through node 831 to store 
identifier process 850 when the current display card is 

15 the last card in the deck. 

If the current card is not a display card but is 
an entry card, display card check 841 transfers to 
entry card check 843. In this embodiment, the next key 
is the predetermined key used to indicate that all the 

2 0 data for an entry on an entry card has been entered. 

Thus, if the current card is an entry card, entry card 
check 843 transfers processing to store data 
process 844 . 

Store data process 844 stores the data entered in 
25 at an appropriate location in memory that is specified 
in the current entry card. Typically, the data is 
combined as an argument with a URL and stored. Upon 
completion, store data process 844 transfers through 
node 810 to create HTTP request process 802 (Fig. 8A) . 

3 0 When the next key is pressed, if the current card 

is neither a display card nor an entry card, the 
current card is a choice card. However, as indicated 
above, in this embodiment client module 702 requires 
that the user make a choice and does not allow use of 
35 the next key. Consequently, if the current card is not 
an entry card, entry card check 843 transfers 
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processing through node 813 to key press check 820. 

The previous discussion assumed that the next key 
was pressed and so next key check 84 0 transferred 
processing to display card check 841. However, if the 
next key was not pressed, next key check 840 transfers 
processing to previous key check 846. If the previous 
key was pressed, check 846 transfers to first card 
check 847 and otherwise returns processing to key press 
check 820. 

First card check 847 determines whether the 
current card is the first card of a deck. If the 
current card is not the first card, processing 
transfers from first card check 847 to read previous 
card 84 9, which in turn reads the previous card and 
transfers to generate display process 809 through 
node 813. Conversely, if the current card is the first 
card, processing transfers to home deck check 848. 

If the current card is the first card in the home 
deck, there is not a previous ^card and so home deck 
check transfers processing toVkey press check 82 0 
through node 813 and so the previous key press is 
ignored. If the current deck is not the home deck, 
home deck check 848 retrieves the identifier for the 
previous deck and transfers through node 831 to store 
identifier process 850. 

Store identifier process 850 is reached through 
node 831 from several different points. The operations 
in store identifier process 850 are the same 
irrespective of the particular process that transfers 
to process 850. In each instance, an identifier is 
passed to store identifier process 850 and process 850 
saves the identifier in working memory 716. The 
identifier can be, for example, a pointer to another 
location in the current card, an address of another 
card in the current deck, a URL to a deck stored in 
working memory 716, a URL to a TIL deck in TIL 
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decks 760 on computer 743, or perhaps, a URL to a 
common gateway interface program in CGI programs 761 on 
computer 743. Thus, process 800 checks the stored 
identifier to determine the action required. 
5 Specifically, in identifier to current deck , 

check 851, client module 702 determines whether the 
identifier is to a card in the current deck. If the 
identifier points to the current deck, check 851 
transfers processing to retrieve data process 8 52 and 

10 otherwise to URL to local deck check. 853. 

In retrieve data process 852, client module 702 
retrieves the information stored at the location 
indicated by the identifier from working memory 716 and 
processes the information. Retrieve data process 8 52 

15 transfers through node 812 to generate display 809 
(Fig. 8A) that was described above. 

URL to local deck check 853 determines whether the 
identifier is a URL- to a deck that is stored in working 
memory 716, e.g., cached. If the deck is stored 

20 locally, check 853 transfers to retrieve local deck 854 
which in turn moves the local deck into the storage 
location for the current deck. Retrieve local deck 8 54 
transfers processing through node 811 to process first 
card 808 (Fig. 8A) , that was described above. 

25 If the identifier is neither to a location in the 

current deck, nor to a local deck, the identifier is a 
URL to an object on computer 743. Thus, in this case, 
check 853 returns processing to create HTTP request 8 02 
through node 810. 

3 0 Process 800 continues so long as the user 

continues to enter and process the information 
provided. In this embodiment, process 800 is 
terminated, for example, either by the user powering - 
off cellular telephone 700, selecting a choice or entry 

35 card that discontinues operations of client module 702, 
or remaining inactive for a time longer than a time-out 
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period so that client module 702 shuts itself down. 

To further illustrate the operations in 
process 800, consider the following example which is 
returned to client module 702 as a TIL deck in response 
5 to a HTTP request generated by process 802, For 

readability, Table 2 presents the deck in PIDL. In 
this example, all of the choices are for applications 
on the same server. However, in another embodiment, 
each URL could address any desired combination of 
10 servers. 

/ TABLE 2 

, , .... . EXAMPLE OF PIDL CHOICE DECK 
<PIDL> 
<CHOICE> 

15 <CE URL=http: //www. libris. com/airnet/nnn>News 

<CE URL=http : //www. libris . com/airnet/www>Weather 
<CE URL=http : //www .libris . com/airnet/sss>Sports 
</CHOICE> 
</PIDL> 
20 

In process first card 808, client module 702 interprets 
the information in Table 2 and transfers to generate 
display process 809. In generate display process 809, 
client module 702 sends information to display 
25 module 712 so that the user is presented with a list of 
three choices on display screen 705, i.e, a user 
interface for the choice card is generated: 

1 . News 
3 0 2. Weather 

3 . Sports 

Generate display process 809 (Fig. 8A) transfers 
to key press check 820 (Fig. 8B) . When the user 
3 5 presses the two key on keypad 715, key press check 820 
transfers through check 821 to display card check 823. 
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Since the current card is a choice card, check 823 
transfers processing to choice card check 824, which in 
turn transfers to choice key check 826. Since the two 
key was pressed and that key is a choice key, check 826 
transfers processing to store identifier process 850 
(Fig. 8D) . In process 850, client module 702 stores 
the URL corresponding to two, i.e, 

URL=http : //www. libris . com/airnet/www 



in working memory 716 . 

Since this URL is to an object on computer 743, 

processing transfers through checks 851 and 853 to 
Q create HTTP request process 802, which in turn 

!~? 15 generates the request. When the HTTP request is 
\Q transmitted to server 74 9, as described above with 

respect to process 804, server 74 9 in service request 
hj process 862 retrieves deck www from TIL decks 760. An 

example of the deck is given in Table 3. Again for 
ij\ 20 readability, the deck in present herein in PIDL. 




TABLE 3 

EXAMPLE OF A SECOND PIDL CHOICE DECK 

25 <PIDL> 

<CHOICE> 

<CE URL=http : //www. libris . com/airnet/www- l>World 
<CE URL=http : //www . libris . com/airnet 

/www- 2 >Nat ional 
30 <CE URL=http : //www. libris . com/airnet/www- 3 >State 

<CE URL=http : //www. libris . com/airnet/www- 4 >Local 
</CH0ICE> 
</PIDL> 



35 The deck in Table 3 is transmitted to cellular 

telephone 700 and stored in memory 716, as described 
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above with respect to process 806 . The choice card is 
processed in process 808 and displayed in process 809. 
As a result of process 809, the user is presented with 
a list of choices: 

1. World 

2. National 

3 . State 

4 . Local . 

When the user makes another selection, the same 
sequence of processes as described above for the first 
choice card is executed by client module 702, and 
another URL is stored that points to a program on 
server 74 9 that retrieves the desired weather 
information and generates a deck with that information. 
This deck is transferred to cellular telephone 700 and 
displayed. 

As described above, if the current card is an 
entry card and. a key is- pressed, client process 702 
reaches data key press check 826 (Fig. 8B) . If the 
pressed key is a valid data key, check 826 transfers to 
process data entry 827. 

In one,. embodiment , process data entry 82 7 uses a 
novel predictive text entry process for text entry. 
Recall that on a typical telephone keypad, the keys are 
labeled with both a number and two or three letters. 
For example, the two key is also labeled abc . This 
leads to some ambiguity when using the telephone keypad 
to enter text. Is the user attempting to enter an a, 
b, or c when the two key is pressed? 

In one prior art method, two keystrokes were 
required to enter each letter of text. The first 
keystroke identified the first key and the second key 
stroke identified the specific letter desired on the 
first key. For example, to enter the letter s, the 
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user would first press the seven key that is labeled 
with letters p, r, and s. Next, the user would press 
the three key to select the letter s. While this 
method may work well for short sequences that consist 
5 of only three or four letters, the method does not work 
well for English text. For example, if the user has 
already entered th and then presses the three key that 
is labeled with letters d, e, and f, almost always the 
desired next letter is the letter e. Therefore, making 
10 the user press the two key is an extra and unnecessary 
step. 

Client module 702 of this invention utilizes a 
novel predictive text entry process to reduce the 
number of key strokes required to enter text using a 

15 telephone keypad, or any similar keypad. Using this 

process, in most cases a single key stroke suffices to 
enter a single letter. 

While this embodiment of the invention is 
described in terms of a telephone keypad, the 

2 0 principles of the invention are not limited to only a 
telephone keypad. In general, the process described 
more completely below, can be extended to any keypad 
where a single key is used to enter two or more 
letters. Further, the process is not limited to only 

2 5 letters, but rather i;s> applicable to any keypad where a 

single key is used to represent two or more characters. 
In view of the following disclosure, those skilled in 
the art can use the principles of the predictive text 
entry process in a wide variety of applications. 

3 0 The system for predictive text entry includes a 

predictive text entry module 901 that in this 
embodiment is included in client module 702, keyboard 
module 711, and a letter frequency table 902 that is 
loaded into memory 716, when client module 702 is 
35 activated. Predictive text entry module 901 is used in 
process data entry 827 when specified by the current 
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entry card. Predictive text entry module 901 performs 
routine buffer management processes, that are known to 
one of skill in the art and so are not described 
further to avoid detracting from the process. 
5 Predictive text entry module 901 stores a letter 

entry for each letter entered in a text buffer 903 in 
memory 716. In this embodiment, letters Q and Z are 
assigned to the one key and the zero key is used to 
enter a space, period, and comma, i.e., the zero key 

10 provides punctuation. However, these assignments are 
illustrative only, and are not intended to limit the 
invention to this particular embodiment. 

The first letter entered is placed at the left end 
of the buffer and each additional letter is placed in 

15 the left most unused space in buffer 903. Thus, the 
last letter entered in text buffer 903 is the right 
most character. Letter frequency table 902, sometimes 
referred to as a table of predictive letter entries, is 
a look-up table where each entry in the look-table is 

20 addressed by three indices. The first two indices 

represent the two most recently entered letters in text 
buffer .903 and the third dndex represents the key that 
was pressed. Each predictive letter entry stored m 
letter frequency table 902 defines which of the letters 

25 associated with the pressed key to use given the 

previous two letters. For example, since the is a 
commonly occurring string, the entry in table 902 
addressed by (t, h, 3) returns e, or more concisely 
the predictive letter entry 2 is returned to indicate 

30 that the second letter of the group of letters d, e, 
and f associated with the three key is the predicted 
letter. Of course, letter frequency table 902 could be 
altered to return more than a single letter. 

In this embodiment, letter frequency table 902 was 

35 empirically generated using a collection of e-mail. 

Appendix II is a computer program listing that was used 
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to generate letter frequency table 902 that is 
illustrated in Figures 10A to 10T. Briefly, the 
computer program implements a process that sequentially 
steps through the data provided and (i) for each 
5 possible single letter determines the most likely 

letter that follows for each key on the keypad; and 
(ii) for each possible combination of two letters 
determines the most likely letter that follows for each 
key on the keypad. In this embodiment, the most likely 

10 letter is the letter having the greatest frequency 

after the single letter. Similarly, the most likely 
letter is the letter having the greatest frequency 
after the combination of two letters. If there is a 
tie in the frequency, the first letter associated with 

15 a key is selected. Of course, other measures of 

likelihood could be used to generate the entries in 
table 902. 

Thus, in Figures 10A to 10T, the first of the ten 
columns, i.e., the left most column, is the two letter 
20 sequence and the first row, i.e., the top row is the 

keys on the key pad used to enter text. A combination 
of an entry in the first column and a key in the top 
row is used to select the predicted text entry. Thus, 
using the example of th, this two key sequence appears 

2 5 in the first column of Figure 10O. When the three key 

is pressed, the letter in the row with th as the first 
entry and in the column with three as the first entry, 
i.e., e, is retrieved. Alternatively, if the four key 
is pressed, letter i is retrieved from the table. 

3 0 In this embodiment, table 902 is a buffer of two 

bit numbers. Each two bit number has a value in the 
range of zero to three, and the two bit number 
represents a predicted letter for the pressed key. 
Thus, for a two key labeled with letters A, B and C, a 
35 zero represents A; a one represents B; and a two 

represents C. In general, the number of bits used is 
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determined by the key that represents the maximum 
number of characters. In this embodiment, the maximum 
number of characters represented by a key is three. 
The number of storage bits required is an integer S 
5 where S is the smallest number such that 2**S is 
greater than or equal to the maximum number of 
characters represented by a key. 

In this embodiment, three indices iO, il, and i2 
are used generate a table index that in turn is used to 

10 access a particular predictive letter entry in 
table 902 of two bit numbers. Each letter is 
represented as a number, i.e., a letter entry, with 
letter A being zero, letter B being a one, letter C 
being a two, and so forth with letter Z being twenty- 

15 five. A space element is assigned a space element 

value of twenty- six. Thus, in this embodiment, there 
are twenty- seven possible characters. 

Upon the initial entry to. process 1100 (Fig. 11), 
letter indices iO, il, and i2 were set to twenty-six in 

20 the initial processing of the entry card to indicate 

that the text buffer is empty. Also, as explained more 
completely below, as each letter of text is entered, 
letter indices iO and il are updated and stored in 
memory 716 . 

25 However, in another embodiment, an initialize 

indices process is the first operation in predictive 
text entry process 1100. In this embodiment, for the 
first letter entered, letter indices iO and il are set 
to twenty six; for the second letter entered, letter 

30 index iO is set to twenty six and letter index il is 

set to the value of the letter in text buffer 903; and 
for all letters entered after the first two, the value 
associated with next to the last letter in text 
buffer 903 is assigned to letter index iO and the value 

35 associated with the last letter in text buffer 903 is 
assigned to letter index il. 
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Punctuation key check 1101 determines whether the 
zero key was pressed, i.e., the key selected to 
represent punctuation . 

If the zero key was pressed, processing transfers 
5 from check 1101 to process punctuation entry 1102. 

Process punctuation entry 1102 sets index i2 to twenty- 
six, and sends the space element value to display 
letter process 1108. Display letter process 1108 
transfers the space element value to display module 712 
10 which in turn drives a space in the text entry on 

display screen 705. This completes the operation of 
process data entry for a zero key press and so 
processing returns to key press check 820. 

If the zero key was not pressed, processing 
15 transfers through punctuation key check 1101 in data 

entry process ll f 00 to key one-to-nine check 1103, i.e., 
to a data entry key check. If the pressed key was any 
one of keys one to nine, check 1103 transfers to set 
letter index process 1104 and otherwise to rotate last 
20 entry process 1109. 

In set letter index process 1104, one is 
subtracted from the numeric value of the pressed key 
and the resulting value is assigned to index i2 . Set 
index process 1104 transfers to generate table index 
25 process 1105. 

Generate table index process 1105 combines 
indices iO, il and i2 to create a table index. In this 
embodiment, table index TABLE_INDEX is defined as: 

30 TAB LE_ I NDEX = (((i0 * 27) + il) * 9) + i2 

Upon completion of generate table index process 1105, 
generate text entry process 1106, retrieves the two bit 
value in the table at the location pointed to by table 
35 index TABLE_INDEX and converts the two bit value to a 
letter represented by the two bit value. 

-71- 



72- 



L:\DMS\7574\M-3423_U\0135864.04A 

0 



Generate text entry process 1106 transfers to 
update index procetss 1107, which in turn stores the 
value of letter index il as letter index i0; stores the 
value of the retrieved letter in letter index il; and 
5 stores the predicted letter in text buffer 903 . While 
this step assumes that letter indices iO, and il are 
stored and accessed each time in process 827, 
alteratively, the last two letters in text buffer 903 
can be retrieved and assigned to indices iO and il, 
10 respectively, as described above. 

Update index process 1107 transfers to display 
letter process 1108. Display letter process 1108 sends 
information to display module 712 which in turn 
^ generates the predicted letter on display screen 705. 

ifi 15 If the pressed key is not one of keys one to nine, 

! !! : i.e, is not a data entry key, processing transfers from 

bfj check 1103 to rotate last entry 1109. Recall that data 

key check 82 6 determined whether the pressed key was 
Li one of the zero to nine keys, or the # key. Thus, 

s; 20 since checks 1101 and 1103 determined that keys zero to 

l2 nine were not pressed, the only key press remaining is 

SU the # key, i.e., the rotate entry key, which indicates 

s fr the user wants a letter different than the one entered 

m last in text buffer 903. In rotate last entry 1109, 

25 the last character, i.e., the right most character, in 
text buffer 903 is replaced by the next character in 
the set of characters assigned to the last key pressed 
before the # key was pressed. Again, the use of the # 
key is illustrative only and is not intended to limit 
3 0 the invention to the use of that particular key to 
rotate an entry. 

For example, if the last character in the text 
buffer 903 was a t and the # key is pressed, 
process 1109 changes the t to u. If the # key is 
35 pressed again, the u is changed to a v. Alternatively, 
if the last character in text buffer 903 was a u and 
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the # key is pressed, process 1109 changes the u to a 
v. If the last character in text buffer 903 was a v 
and the # key is pressed, process 1109 changes the v to 
at. If index il is stored, as the last character in 
text buffer 903 is rotated, index il is updated. 

Text entry in cellular telephone 700 in different 
languages or contexts can be supported by using 
different letter frequency tables. For example, for 
plumbers, the prediction table can be based on text 
about plumbing procedures. For Frenchmen, the 
prediction table can be based on French text. Also, 
multiple letter frequency tables could be stored in 
cellular telephone 700, or selectively transmitted to 
cellular telephone 700, and a particular letter 
frequency table would be selected on an entry card. 

In addition, an entry in the table can be more 
that a single letter, and thus save even more key 
strokes. For example,^ if the text buffer contains sche 
then typing a 3 could return dule rather than just d. 
Further, this novel method of text entry can be 
utilized with other than a cellular telephone. The 
method is applicable to any device that has several 
characters assigned to a single key on a keypad. 

In the above embodiment, the English alphabet and 
a space element were used as the character set. Thus, 
the number 27 used in defining the table index is just 
the number N of characters in the set. Similarly, the 
number 9 used in defining the table index is just the 
number M of keys in the keypad that represent two or 
more different characters. Hence, predictive text 
entry method of this invention is not limited to text 
and is directly applicable to any keypad where each key 
represents a plurality of different characters. 

In the embodiment of Figures 7, 8, and 9, client 
module 702 and server module 74 9 communicate over CDPD 
network 710. However, this architecture is 
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illustrative only of the principles of the invention 
* and is not intended to limit the invention to the 

particular architecture described. Client module 702 
and server module 74 9 can use a wide variety of two-way 
5 data communication links to exchange resource locators, 
e.g., URLs, and TIL decks. For example, the 
communications link could be a switched voice circuit 
in which the client module and server module 
communicate using modems. Alternatively, the 
10 communications link could be any other packet switched 
network, so long as there is some way for client module 
702 to get requests to server module 74 9 and for server 
module 749 to send data back to client module 702. 
Further, a special purpose server could be used in 

sf3 15 place of HTTP server 74 9. For example, the principles 

H of this invention can be used over various data 

transport mechanisms including circuit switched data 

|=* and packet switched data. These data transport 

mechanisms are being defined and implemented for most 

5 . 2 0 of the cellular network standards including GSM, TDMA, 

and CDMA. 

jny In the configuration of airnet \ 

=P network 750 (Fig. 7) , client module 702 communicated 

]S directly with a server computer 743 . In another 

25 embodiment, as illustrated in Figure 5, the two-way 
data communication device first communicates with an 
airnet network translator 500 that in turn communicates 
with the appropriate server. In this embodiment, the 
operation of two-way data communication devices 100, 
30 101, and 102 is similar to that described above for 

cellular telephone 700, except the method field in the 
request generated in process 802 has a different form. 
For example, using the same information as before, the 
method field in this embodiment is: 
35 GET http://www.libris.com/airnet 

/home . cgi?&cost=l ANTP/1 . 0 
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The method field includes the full address of the 
server, the expected cost of the service, and the 
version of the protocol used for communicating with 
5 airnet network translator 500. The two-way data 
communication device transmits the HTTP request 
including the complete URL to airnet network 
translator 500. 

Figure 12 is a more detailed block diagram that 
10 illustrates the structures in one embodiment of airnet 
network translator 500, according to the principles of 
this invention. In this embodiment, airnet network 
translator 500 is a computer running under the UNIX 
operating system with an interface to CDPD network 710. 
!Pt 15 Such computers are well known to those skilled in the 

H art. Thus, herein only the structures and processes 

that must be added to such a computer are described. 
M Airnet network translator 500 supports internet 

protocol (IP) connections over CDPD network 710 and 

fisSSB; 

S[ 20 with each computer network with which translator 500 

1^ can interact. In this embodiment, each of the modules 

in network translator 500 are processes that are 
,p executed by the processor in the computer. Control 

^ module 1201 is a daemon that listens for transmissions 

25 over an IP connection from CDPD network 710. When 
control module 1201 accepts a transmission, control 
module 1201 spawns an ANT request processor 1204, which 
in this embodiment is a process, as indicated above. 
While in Figure 12, only one ANT request processor 1204 
3 0 is shown, there is an ANT request processor spawned for 
each transmission that control module 1201 accepts and 
the ANT request processor remains active until the 
communication is terminated. 

Figure 13 is a process flow diagram that 
35 illustrates the operation of ANT request 

processor 1204. This process flow diagram considers 
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transmissions that utilize both TCP/IP and UDP/IP. 
However, the processes that are specific only to TCP/IP 
are enclosed in dashed-line boxes. Upon being spawned 
for a TCP/IP, in establish connection process 1300, ANT 
5 request processor 1204 establishes a TCP connection 

using a TCP module in the server with the client module 
over CDPD network 710. After the connection is 
established processing transfers from process 1300 to 
request received check 1301. 1 

10 If UDP is being used, upon being spawned ANT 

request processor 1204 initiates processing in request 
received check 1301. In check 1301, ANT request 
processor 12 04 determines whether the request from 
cellular telephone 700 (Fig. 12) has been received and 

15 stored in memory 1210. Memory 1210 represents both RAM 
and non-volatile memory in this embodiment. When the 
request has been received and stored, processing 
transfers from check 13 01 to retrieve data 
process 1302 . 

20 In retrieve data process 1302, ANT request 

processor 12 04 retrieves information concerning the 
source of the URL, i.e., client module 702 of cellular 
telephone 700 from customer database 1213, and the 
destination specified in the URL, i.e., the designated 

25 server, from server database 1212. Both databases 1212 
and 1213 are stored in memory 1210. A customer record 
in database 1213 includes, for example, a carrier 
address, e.g., an IP number, an airnet network 
translator account number, billing information, and 

30 server subscriptions. A server record in database 1212 
includes a server IP address, name, category, and class 
of service. Class of service refers to the pricing of 
the service, e.g., basic services, premium services, or 
pay-per-view services. Other pricing schemes can be 

35 supported in other implementations. When the 

information is retrieved for the server and service 
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specified in the URL, and for the customer, processing 
transfers to valid request check 1303. 

In valid request check 1303, ANT request 
processor 1204 determines, for example, whether client 
module 702, i.e., the customer, is authorized to access 
airnet network translator 500; whether client 
module 702 is authorized to access the server specified 
in the URL; whether the specified server is available 
through translator 500; and whether the specified 
server supports the requested service. Thus, valid 
request check 1303, validates the client, the server, 
and the client /server pair. Also, since an estimated 
cost is included in the request, the status and credit 
limits on the customer's account could be checked to 
determine whether the estimated cost is acceptable. If 
all of the checks are true, processing transfers to 
create HTTP request process 1306. Conversely, if any- 
one of the checks is untrue, valid request check 13 03 
passes information concerning the error to return error 
process 1304. 

Return error process 13 04 launches a CGI program 
stored in memory 1210 based on the information received 
and passes appropriate information to the CGI program. 
The CGI program builds an appropriate PIDL deck 
describing the error and converts the PIDL deck to a 
TIL deck, as described above. When the TIL deck 
describing the error is complete, return error 
process 13 04 transfers processing to log transaction 
process 1315 that is described more completely below. 

If all the checks in valid request check 1303 are 
true, create HTTP request 13 06 converts the request in 
memory 1211 to a request specific to the server 
specified, which in this embodiment is a HTTP request. 
For example, for the above request, create HTTP request 
process 1306 generates a method field, such as 
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GET /airnet/home.cgi?&client=xyz&cost=l HTTP/1.0 

In this embodiment, the method field includes the same 
information as in the embodiment described above, and 
5 in addition, the method field includes a client 
identification and the estimated cost. 

After create HTTP request process 1306 is 
complete, ANT request processor 1204 accesses TCP 
module 1203 in establish server connection process 1307 

10 for TCP/IP and transfers to secure transmission 
check 1308 for UDP/IP. In establish connection 
process 13 07, a connection is made between the server 
designated in the client request and the TCP interface 
module (not shown) so that data can be transmitted 

15 between airnet network translator 500 and the server. 
When the TCP connection to the server is established, 
ANT request processor 1204 transfers processing from 
establish server connection process 1307 to secure 
transmission check 1308. 

20 In secure transmission check 1308, ANT request 

processor 12 04 determines whether the HTTP request from 
the client requested a server that utilizes a protocol 
that supports encryption. If such a server was 
requested, processing transfers to negotiate 

25 process 1309 and otherwise to transmit request 
process 1310. 

In negotiate process 1309, ANT request 
processor 1204 negotiates an encryption technique with 
the server. Upon completion of the negotiation, 

30 processing transfers from process 1309 to encryption 
process 1311. In encryption process 1311, the HTTP 
request is encrypted using the negotiated encryption 
technique, and then processing transfers to transmit 
request process 1310. 

35 In transmit request process 1310, the HTTP request 

is sent from memory 1210 to the HTTP server. When the 
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transmission is complete, ANT request processor 1204 
goes to result received check 1312. 

As described above, upon receipt of the request, 
the HTTP server services the request. Upon completion 
of servicing the request, the HTTP server returns 
either a PIDL deck or a TIL deck to airnet network 
translator 500. The deck is stored in memory 1210. If 
the server does not convert the PIDL deck to a TIL 
deck, the translation is done by airnet network 
translator 500. 

When the deck is received and stored, ANT request . 
processor 1204 transitions from check 1312 to 
transmission completed process 1313 for TCP/IP and to 
secure transmission check 1314 for UDP/IP. ANT request 
processor 1204 closes the TCP circuit with the server 
in transmission completed process 1313. Upon closing 
the server TCP connection, processing transfers to 
secure transmission check 1314. 

If the server utilized encryption, the deck stored 
in memory 1210 is encrypted. Thus, secure transmission 
check 1314 transfers processing to decryption 
process 1316 if encryption was used and otherwise to 
log transaction 1315. 

In decryption process 1316, the encrypted deck is 
decoded and stored in memory 1210. Also, after the 
decoding, if the deck must be converted to a TIL deck, 
the translation is performed. Decryption process 1316 
transfer to log transaction process 1315. 

In log transaction process 1315, ANT request 
processor 1204 writes a description of the transaction 
to transaction log 1211 in memory 1210. In this 
embodiment, each transaction record includes a customer 
identification, a server identification, time required 
for the transaction, cost of the transaction, and a 
completion code. In one embodiment, for security 
purposes, each cellular telephone is assigned to only 
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one customer and only one account . 

After the transaction is logged, processing 
transfers to transmit result 1317. In transmit 
result 1317, ANT request processor 1204 returns the 
deck to client 702. After the deck is transmitted, ANT 
request processor 1204 is terminated. 

In one embodiment, if an airnet network translator 
is fully loaded and another transmission comes in, the 
translator returns the address of another airnet 
network translator and refuses the transmission. The 
cellular telephone transmits the message to the other 
airnet network translator. In yet another embodiment, 
all incoming transmissions are directed to a router. A 
plurality of airnet network translators are connected 
to the router. The router monitors the status of each 
translator. Each incoming transmission is routed to 
the least busy translator, which in turn responds to 
the transmission and performs the necessary operations 
for continuing communications with the client module. 

In the above description of client module 702, 
module 702 interacted with components within the 
cellular telephone to perform the various operations 
specified by the user. To insulate client module 702 
from the exigencies of various cellular telephones to 
the extent possible, '$a general architecture for client 
module 702 is described more completely below. This 
general architecture is designed to have specific 
manager modules that interact with the modules 
described above within the cellular telephone and to 
provide standard information to the remaining manager 
modules within client module 702. The manager modules 
with client module 702 form an interpreter that 
interprets TIL decks to generate a user interface; 
interprets data input by the user; and interprets the 
TIL decks so that the data input by the user is 
combined with an appropriate resource locator and 
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either a message is sent to an appropriate server, or 
another local TIL deck is interpreted by client 
module 702. While this embodiment is for a cellular 
telephone, the manager modules are generic and so are 
5 applicable to any client module in a two-way data 
communication device . 

This approach limits the modifications that must 
be made to client module 702 to implement the 
principles of this invention in a wide variety of two- 

10 way data communication devices over a wide variety of 
two-way data communication networks. Also, in the 
above embodiment, client module 702 supported 
communications and interactions over the cellular 
telephone network. However, client module 702 can also 

15 support local services on cellular telephone 700. 

Typical local services includes local messages, an 
address book, and preconf igured e-mail replies, or any 
combination of such services. .' ' 

In this embodiment, client module 702 includes a 

2 0 plurality of manager modules including a navigation 

manager module 1401, a network manager module 14 02, a 
TIL manager module 1403, an archive manager 
module 1404, a local manager module 1405, an event 
manager module 1406, a timer manager module 1407, a 
25 user interface manager module 1408, a memory manager 
module 1409, and a device dependent module 1410. 

Navigation manager module 14 01 handles card and 
deck navigation as well as managing any caches. 
Navigation manager module 1401 owns and manages a 

3 0 history list and as well as a pushed card list. In 

addition, navigation manager module 1401 functions as 
the main line of client module 702; does all event 
distribution; and supports local services. 

For local services, like local message store, 
3 5 there are two basic approaches that can be used. 

First, local services are implemented in a CGI-like 
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manner. Each local service has an entry point which is 
called with an argument list. A TIL deck is returned 
via the event manager. From that point on, the TIL 
deck is processed in the standard manner. This 
5 approach limits local services to the same constraints 
as remote services. A less restrictive approach is to 
allow the local service to field events instead of the 
standard event loop. The local service would construct 
TIL cards on-the-fly and feed them to user interface 

10 manager 1406. Note that the local service would need 
to cooperate with the standard event loop with regard 
to the history, the pushed card list, and any other 
state that is normally managed by the event loop. 
Table 4 is a listing of processes for the architecture 

15 for navigation manager module 1401. 



TABLE 4 

ARCHITECTURE FOR NAVIGATION MANAGER MODULE 14 01 

2 0 ProcessEvents (void) ; 

PushLocation (void * location, Boolean forStack) ; 
void * PopLocation (Boolean forStack) ; 
void * CurrentLocation ( ) ; 
struct LOCAL_SERVICE { 
2 5 char name [5 0] ; 

FUNC HandleEyent (Event * pevent); 
FUNC StartLocalService (void) ; 
FUNC StopLocalService (void) ; 

}; 

30 static LOCAL__SERVICE localServices [] ={ ... }; 

STATUS HandleEvent (Event * pevent); 
STATUS StartLocalService ( ) ; 
STATUS StopLocalService ( ) ; 




3 5 Routine ProcessEvents is the main entry point for 

event processing in client module 702 . Typical events 
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include key presses on the keypad, choice selection for 
a choice card, text entry for an entry card, network 
events, and history events. Routine ProcessEvents can 
be called at any time to process an event or events. 
Routine ProcessEvents does not return until all events 
on a queue generated by event manager module 1406 are 
processed. If a local service is running, events are 
distributed to the local service before being processed 
by routine ProcessEvents. 

The remaining routines in Table 4 are called 
internally to navigation manager module 14 01 and by 
local services. Routine PushLocation pushes a location 
on the history list and issues a request for that 
location. The forStack flag indicates a stack push of 
local cards . 

Routine *PopLocat ion pops a location on the 
history stack and issues a request for the top location 
of the history stack. In routine *PopLocation the 
forStack flag indicates that all cards since the last 
stack push should be popped. 

Routine *CurrentLocation returns the current 
location the current URL being displayed. 

As shown in Table 4 , each local service provides a 
number of functions. If a local service is running, 
function HandleEvent , the local service's event 
handler, is called before any processing by navigation 
manager module 1401. If the event is handled by the 
local service, the event is not processed any further. 

Function StartLocalService is the local services 
start function. Function StartLocalService is called 
before any events are distributed to the local 
function. Similarly, function StopLocalService is the 
stop function for the particular local service. 
Function StopLocalService is called when no more events 
are distributed to the local service. 

Network manager module 1402 insulates the rest of 
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client module 702 from the specific networking protocol 
used over the cellular telephone network. Network 
manager module 1402 delivers requests to the server 
specified in the URL via the cellular telephone network 
interface; segments responses from the server for lower 
latency; delivers responses from local services to 
navigation module 1401 via event module 1406; handles 
request /response cycle (e.g. cancellation, retry 
strategy) with the server over the cellular telephone 
network; can receive asynchronous messages from the 
server; performs memory management of TIL decks; 
performs caching of TIL decks; handles all negotiations 
concerning protocols and server scaling with the 
server; handles any encryption for information 
exchanged between cellular telephone 700 and the 
server. 

In some cellular telephone, the- maximum message 
size is fixed. However, for UDP and TCP messages, a 
more direct interface is used that bypasses this 
limitation of message passing. It is important to 
avoid copying network data from memory buffer to memory 
buffer as such copying increases the memory "high water 
mark" as well as decreases performance. Since 
different cellular telephones have different interfaces 
for delivering network data, network manager 
module 1402 manages the network data. In this way, 
network data is only .copied from the network buffer for 
long-term storage. 

When a message or reply arrives, network manager 
module 14 02 uses event manager module 14 06 to report 
that fact. However, access to the data by other 
manager modules in client module 702 is through a 
protocol that allows storage of data in a variety of 
fashions on different telephones. Any transparent, 
short-term caching of TIL data is handled by network 
manager module 1402. Table 5 is one architecture for 
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TABLE 5 

SPECIFICATION FOR NETWORK MANAGER MODULE 1402 

5 

typedef short TID; 
void NM_Init (void) ; 
void NM_Terminate (void) ; 

TID NM_SendRequest (void *requestData, int length, 
10 Boolean ignoreCache) ; 

NM_CancelRequest (TID TRANSACT I ONI d) ; 
NM_DataType (TID TRANSACT I ON I d ) ; 

NM_GetData (TID TRANSACT I ONId, void *data, int 
*length, Boolean *complete) ; 
15 void *NM_HoldData (TID TRANSACT I ONI d) ; 

NM_ReleaseData (TID TRANSACT IONI d) ; 

TID NM_StartData (int data Type,, char *requestData, 

int length) ; 
STATUS NM_EndData (TID TRANSACT I ONI d) ; 
2 0 STATUS NM_SetDataLength (TID TRANSACTIONId , int 

length) ; 

STATUS NM_GrowDataLength (TID TRANSACT IONI d, Int 
grow) ; 

int NM_GetDataLength(TID TRANSACT IONI d) ; 
2 5 r|v:bid *NM_GetDataPointer (TID TRANSACT I ONI d) ; 

; STATUS NM_DeliverData (TID TRANSACT IONI d) ; 

Network manager module 1402 identifies each 
30 network data transaction by a 16-bit transaction 

identification code TID. Network manager module 1402 
increments transaction identification code TID by one 
for each new transaction. Transaction identification 
code TID rolls over after Oxffff . 
35 Routine NM_Init initializes network manager 

module 1402 and so is called before any other calls in 
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network manager module 1402. Routine NM_Terminate 
closes processing of network manager module 1402 and so 
is called after all other calls in network manager 
module 14 02. 

Network manager module 1402 uses routine TID 
NM_SendRequest as the standard process of sending a 
request to the server. Pointer *requestData in the 
call to routine TID MN_SendRequest is defined by the 
server protocol. Similarly, the state, e.g., the 
Boolean value, of variable ignoreCache is used to 
indicate whether any cached replies should be ignored. 
After sending the request, this routine returns a 
server transaction identification code TRANSACT I ONI d . 
A local service can also send a request to the server. 

When the user instructs client module 702 to 
cancel a request, network manager module 1402 calls a 
routine NM_CancelRequest with cellular telephone 
transaction identification code TID and server 
transaction identification code TRANSACT I ONI d . Routine 
NM_CancelRequest issues a command to the server to 
cancel the specified request. 

When data are received from the network, the data 
can be either a response to a request sent by 
routine TID MN_SendRequest , or by a local service. 
Thus, in response to receiving data from the server, 
network manager module 14 02 generates an event that 
includes server transaction identification 
code TRANS ACT I ON I d and the type of data DATAType . For 
replies to requests sent by routine TID MN_SendRequest , 
server transaction identification code TRANSACT I ON I d is 
the same as the one returned by the matching call to 
routine TID MN_SendRequest and data type DATAType 
indicates that the data is a response. For local 
service originated messages, server transaction ID is 
new, and data type DATAType depends on whether the data 
is an e-mail, pushed TIL , or another type. 
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yy 15 



20 



25 



30 



After the network event is received by event 
manager module 1406, and navigation manager module 1401 
distributes control of the event to network manager 
module 1402, network manager module 1402 users the 
server transaction identification code TRANSACT I ON I d 
and the remaining routines in Table 5 to process the 
data. 

Routine NM__DataType is used to return the 
particular data type dataTYPE, e.g, reply, MIME, server 
push, etc. Routine NM_GetData sets a pointer to the 
data identified by server transaction identification 
code TRANS ACT I ONI d, retrieves the length of the data, 
and determines whether all the data has been received. 
The interface provided by this routine allows the first 
part of a data stream, e.g. the first card of a TIL 
deck, to be processed by client module 702 before the 
rest of the deck is received. 

Routine NM_HoldData is called before calling 
routine NM__GetData to hold the data and thus insure 
that the data remains valid during processing by client 
module 702. If the data is not held, the data can be 
deleted or moved with the internal buffers of network 
manager module 1402. If the data is held, routine 
NM_ReleaseData is called after network data has been 
processed to release the data. 

Routines TID NM_StartData , NM_EndData, 
NM_Se tDat aLength , NM_GrowDat aLength , NM_Get Dat aLengt h , 
NM_GetDataPointer , and NM_DeliverData are used 
internally by network manager module 1402,. and by local 
services to deliver data. By allowing local services 
to use these routines, the same buffers can be used to 
store both network and locally generated data thereby 
reducing the amount of memory required to support 
client module 702 . 

Routine TID NM_StartData creates a new data 
transaction and triggers a data delivery event. 
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Routine NM_EndData is called when all data for the 
given server transaction identification code 
TRANSACT I ON I d has been transmitted. Routine 
NM_SetDataLength sets the data segment to a given 
5 length and may cause the location of the data to 
change. Routine NM__GrowDataLength grows the data 
segment by a given length and also may cause the 
location of the data to change. Routine 
NM_GetDataLength returns the length of the data 

10 segment. Routine NM_GetDataPointer returns a pointer 
to the data. This routine is preferably called before 
writing into the data buffer. Also, this routine is 
preferably called whenever the data's location may have 
changed. Routine NM_DeliverData can be called when at 

15 least one card has been stored to reduce latency while 
the other cards are being generated. 

TIL manager module 1403 insulates the rest of 
client module 702 from changes to the TIL 
specification. The interface provided by TIL manager 

20 module 1403 has the following characteristics: removes 
the need for parsing by the rest of client module 702; 
uses cursors to avoids generating data structures 
on-the-fly; does not need an entire deck to operate; 
and handles TIL versibning. 

25 Each TIL deck contains a major and a minor version 

number. The minor version number is incremented when 
TIL changes in a way that does not break existing TIL 
manager modules. The major version number is 
incremented for non-compatible versions of TIL. 

3 0 Each TIL deck has the same hierarchy. One 

embodiment of this hierarchy is presented in Table 6 . 
In Table 6, indentation is used to represent the 
relationships of the various hierarchical levels. 
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TABLE 6 
TIL DECK HIERARCHY 

deck 

options 
sof tkeys 

options 

card 

options 
softkeys 

10 options 

formatted text 

formatted lines 
entries 

options 

15 formatted line 



The interface presented in Table 7 for TIL manager 
module 1403 is designed with the assumption that TIL is 
a direct tokenization of PIDL as described in 

2 0 Appendix I. However, the interface does not have any 

dependencies on that tokenization and can support other 
PIDL encoding techniques. Given the above assumption, 
the opaque pointers described below are actual pointers 
into the TIL deck itself. A rudimentary object typing 

2 5 scheme based on where in the deck the opaque pointer 
points can be used to implement the generic functions 
described below. If this object typing is not feasible 
due to details of TTL encoding, the generic functions 
can be replaced with specific functions. 



30 



TABLE 7 

ARCHITECTURE FOR TIL MANAGER MODULE 14 0 3 
typedef char *opaque; 
typedef opaque Deck; 



3 5 typedef opaque Card 

typedef opaque Text 
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typedef opaque Entry; 
typedef opaque Option; 
typedef opaque So ft Key; 
typedef opaque Object; 

5 

/* Generic functions */ 

FirstOption (Object ob j , Option *o) ; 

/* obj is a card, sof tkey, entry, or deck */ 
GetSoftkey (Object obj, Option *o) ; 
10 /* obj is a card or deck */ 

GetText (Object obj, Option *o) ; 

/* obj is a card or entry */ 

/* Deck functions */ 
15 SetDecMDeck d, int length); 

/* tells module which deck to use */ 
DeckGetCard (Card *c, int num) ; 

-or- 

DeckGetCard (Deck d, Card *c, int num) ; 

20 

/* Card functions */ 

int CardType (Card c) ; 
CardFirstEntry (Card c, Entry *e) ; 
CardLookupSof tkey (Card c, int num, Softkey *s) ; 
2 5 CardlsLast (Card c) ; 

/* Option cursor functions */ 
OptionNext (Option *o) ; 
char *OptionKey (Option o) ; 
30 char *OptionValue (Option o) 

/* Entry cursor functions */ 

/* Text (and image) cursor functions */ 

TextNext Token (Text *t, int *type, int *subtype, 
35 int *length, char *data) ; 
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Archive manager module 1404 stores and retrieves 
long-lived information. This information includes: 
data related to the server's location and/or required 
to support server scaling; data related to encryption; 
5 TIL caching (transparent to user) ; TIL storage 

(specified by user) ; and message storage and retrieval 
(see local manager module) . Archive manager 
module 1404 should support a variety of nonvolatile 
memory schemes that are provided by the two-way data 
10 communication devices. 

Local manager module 14 05 is an interface to local 
device resources, such as local messages, address book 
entries, and preconf igured e-mail replies. Local 

_ manager module 1405 should also define an abstract 

Q 

iQ 15 interface to navigation manager module 1401 for use by 
^ archive manager module 14 04 . 

,q Table 8 is an architecture for an interface 

H within local manager module 1405 to access to an 

jT address book stored on cellular telephone 700. The 

si 2 0 name of a routine in Table 8 is descriptive of the 
^7 operations performed by the routine. 

4U % 

s f TABLE 8 

S ARCHITECTURE FOR ADDRESS BOOK ACCESS 

s s :; 

2 5 int NumAddresses ( ) ; 

char *AddressName ( int num); 
char *AddressGetEMail (int num); 

// returns e-mail address 
char *AddressGetPhone (int num); 

3 0 // returns phone number 
char * AddressGeitFax (int num) ; 

// returns fax number 
SetAddress (int num, char *name, char *email, 

char *phone, char *fax) ; 
3 5 DeleteAddress ( int num) ; 

InsertAddress ( int before) ; 
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Table 9 is an architecture for an interface 
within local manager module 1405 to access 
predetermined replies stored on cellular telephone 700. 
The name of a routine in Table 9 is descriptive of the 
5 operations performed by the routine. 



TABLE 9 

ARCHITECTURE FOR PREDETERMINED REPLY ACCESS 

10 int NumReplies ( ) ; 

char * GetReply(int num) ; 
DeleteReply (int num) ; 
SetReply(int num, char *text) ; 
InsertReply (int before) ; 
15 

Table 10 is an architecture for an interface 
within local manager module 1405 to access messages 
stored locally on cellular telephone 700 . The name of 
a routine in Table 10 is descriptive of the operations 
2 0 performed by the routine. 



TABLE 10 

ARCHITECTURE FOR LOCALLY STORED MESSAGE ACCESS 

IB 

25 int NumMessages ( ) ; 

void *FirstMessage ( ) ; 
void *NextMessage ( ) ; 
int MessageType (void *msg) ; 

// e.g. e-mail, TIL, etc. 
void *MessageContent (void *msg) ; 
void *SaveMessage ( int type, void *content, int 

contentLength) ; 
DeleteMessage (void *msg) ; 

35 Event manager module 1406 handles the distribution 

of events. In this embodiment, events include 
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low- level events like key presses and higher level 
navigation and user interface events. There are 
typically only a small number of events at any one 
time. The main event loop in the two-way data 
5 communication device dependent module keeps calling 
EM_Ge t Next Event ( ) until no events are left in the 
queue. Note that processing one event can cause 
another event to be pushed onto the queue . The main 
event loop is not restarted until another event is 
10 pushed onto the queue due to a user key press or a 
network event . 

In this embodiment, the event types include: 

1) keypad events, i.e., pressing of a key; 

2) choice events relating to a current choice 
15 card, e.g., the user selecting choice three; 

3) text entry events relating to a current entry 
card, e.g., the user keying in "Hello"; 

4) network events, . e.g. f response arrived, 
request arrived, transaction terminated, 

20 network status; and' 

5) history events, e.g., pop, pop to marker. 

Table 11 is an architecture for event manager 
module 1406. As in the other tables herein, the name 
25 of a routine in Table 11 is descriptive of the 

operations performed by the routine and in addition a 
brief description is given in the comment field. 

TABLE 1-1 

3 0 ARCHITECTURE FOR EVENT MANAGER MODULE 14 0 6 



struct Event { 
int type; 
void *data; 

3 5 /* e.g. keycode, choice num, entry 

text, status code, other data */ 
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) 

EM_QueueEvent (int type, void * data) ; 

/* Adds event at end of queue*/ 
EM^GetNextEvent (Event * event); 
5 /*Pops next event*/ 

EM_PeekNext Event (Event event) ; 
/* Peeks at next event*/ 



Timer manager module 14 07 allows timer events to 
10 support timeouts, animation, and other time -domain 
features. Timeouts are delivered via event manager 
module 1406. 

Table 12 is an architecture for timer manager 
module 1407. As in the other tables herein, the name 
y3 15 of a routine in Table 12 is descriptive of the 
operations performed by the routine. 



TABLE 12 

ARCHITECTURE FOR TIMER MANAGER MODULE 14 07 
Timerlnit ( ) ; 

int TimerSet (int- milliseconds, Int code, void 

*clientData) ; 
/♦Returns a timer identification timerld to 
be used for cancellations*/ 
TimerCancel (int timerld) ; 
TimerCancelAll ( ) 




3 0 User interface manager module 14 08 handles 

interactions with the keypad and the display. Each of 
the three types of user interfaces defined in Table 1 
above requires a different version of user interface 
manager module 1408. For most cellular telephones, 

3 5 only one card at a time is used. However, some 

cellular telephones can display multiple cards at once 
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and so would require a different version of user 
interface manager module 14 08 from the version that 
handled display of only one card at a time. 

In this embodiment, user interface manager module 
5 provides a user interface for the three types of cards 
display, choice, and entry; provides hooks for custom 
user interfaces for the address list and e-mail reply 
entry; only cares about the user interface aspects of 
cards and provides no navigation, argument, or option 

10 processing; handles all text and graphic layout 

including word wrapping; handles scrolling of text; 
operates from PIDL data structures; generates keyboard 
events, some- of which may be generated by soft keys; 
and generates high-level events, e.g. next card, choice 

15 entry 3, text entry "IBM". 

Table 13 is an architecture for processing cards 
by user interface manager module 1408. - As in the other 
tables herein, the, name of a routine in Table 13 is 
descriptive of the operations performed by the routine. 

20 



TABLE 13 

ARCHITECTURE FOR CARD PROCESSING 
BY UI MANAGER MODULE 14 0 8 

25 void UI_St art Card (Card c) ; 

/* called to begin display and processing of 
a given card*/ 
void UI_EndCard (Card c) ; 

/*called when a card is no longer to be 
3 0 displayed*/ 

Boolean UI_HandleEvent (Event *pevent) ; 

/♦returns true if the event is handled, false 
if not*/ 



35 Table 14 is an architecture for the user 

interface implementation by user interface manager 
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module 1408. As in the other tables herein, the name 
of a routine in Table 14 is descriptive of the 
operations performed by the routine. 



5 TABLE 14 

ARCHITECTURE FOR UI IMPLEMENTATION 
BY UI MANAGER MODULE 14 0 8 

UI_ Layout Card (Card c, Boolean draw, Proc 

callback) 

/* relies on global data; needs to be able 
to: draw as it goes; and note the 
special function of the currentLine 
(e.g. none, choice, sof tkey) */ 
int numLines, f irstVisible , lastVisible, 

currentLine ; 

char currentEntry [8 0] ; 
int currentChoice ; 
void *currentSof tkey ; : 
Card currentCard;' and 

. . . other info as needed for in-line 
scrolling 



The callback routine is notified of the special 
25 function of each line as the line is laid out. Thus, 
routine UI_LayoutCard can be used to scroll to a 
particular choice. If the current line is too wide to 
display all at once, horizontal scrolling is used to 
display the complete line, one display width, at a time. 
30 Memory manager module 1409 is optional, and is 

used in two-way data communication devices that do not 
support dynamic memory allocation. In these devices, 
all memory allocation and releases must go through 
memory manager module 1409. Also, by allocating memory 
3 5 in advance via memory manager module 14 09, client 

module 702 does not run out of memory due to some other 
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process on the device using up memory. 

Microfiche Appendix A is a computer source code 
listing in the C+ + computer language of one embodiment 
of a client module within a cellular telephone, and one 
embodiment of an airnet network translator that was 
used with an Internet server to communicate with client 
module . The Internet server was a UNIX computer 
running the Mosaic HTTP server. The source code was 
used to generate executable code by compiling the 
source code on a computer running the Sun Microsystems 
Operating System Solaris 2.4 using Sun Microsystems 
compiler SunPro C and C#, and the Sun Microsystems SDK 
make utility. All of these products are available from 
Sun Microsystems of Mountain View, California. 

This application is related to copending and 
commonly filed U.S. Patent Application Serial No. 
-Q-8 /XXX , XXX entitled "A PREDICTIVE DATA ENTRY METHOD FOR 
A KEYPAD" of Alain Rossmann, which is incorporated 
herein by reference in its entirety. 

Various embodiments of a novel interactive two-way 
data communication system, a two-way data communication 
device, an airnet network architecture, and a 
predictive text entry system have been described 
herein. These embodiments are illustrative only of the 
principles of the invention and are not intended to 
limit the invention to the specific embodiments 
described. In view of this disclosure, those skilled 
in the art will be able to use the principles of this 
invention in a wide variety of applications to obtain 
the advantages of this invention, as described above. 
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APPENDIX I 
A DESCRIPTION OF PIDL AND TIL 
Unpublished ® 1995 Libris, Inc. 



10 



The main structure of PIDL is described by an 
abstract syntax. This appendix describes the elements 
of the language and their semantics. In the syntax 
description of each element, an element is defined in 
an enhanced BNF. 



15 



20 



25 



a : : = b 


the element a is defined as b 


a : : = b 
: : = c 


the element a is defined as b or c 


b c 


the element b followed by element c, the 
intervening space is just for clarity 


a|b|c 


element a or element b or element c 


{a} 


the 'element a is optional 


{a}* 


the element a may appear zero or more 
times in a row 


{a} + 


the element a may appear one or more 
times in a row 


abc 


the characters abc literally 


ol (a) 


an option list with zero or more topions 
of the element a, see Options below 



In general, the element blank-space can optionally 
appear between any two other elements. To keep the 
diagram clear, it has been omitted except where 
required. Where a blank-space is illegal or treated 
specially, it is, noted. 
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The PIDL ELEMENTS 



deck 

deck-header 
deck -opt ions 
deck- footer 



::= deck-header {softkey}* {card}+ deck- 
footer 

= <PIDL ol (deck-options) > 
= o-args | o-cost | o-ttl 
= </PIDL> 



10 



15 



o-cost 
o-ttl 



A deck consists of one or more cards. 
There must be at least one card. A deck 
may also have a number of softkeys 
defined that stay in force for the whole 
deck. See soft keys below for the 
syntax and full description. 

: : = COSt= value 
: : = ttl= integer 



20 



Additional arguments to be passed on the 
next deck request are given in o-args. 
See Arguments below for syntax and full 
description . 



25 



The cost of retrieving this page 
(exclusive of telephone system charges) 
is represented in o-cost. If no o-cost 
is given, the deck cost is included with 
the user's standard service contract. 



30 



35 



Decks can be cached by the cellular 
telephone for a period of time. The o- 
ttl entry indicates the number of 
seconds that the deck can be cached from 
time of reception. If no o-ttl entry is 
given, the deck can only be cached for 
short periods of time, for example, to 
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implement a back function similar to 
that of most Web browsers. If the value 
of o-ttl is zero, the deck must not be 
cached. 



10 



CARD ELEMENTS 
card : := display-card | choice card | entry- 
card 

A card is one of three types of card in 
this embodiment . These are described in 
the sections below. 



15 



card-options 
o-name 
o-next 
o-prev 



20 



:= o-name | o-next | o-prev 
:= name= identifier 
:= next= destination 
:= prev= destination 
All cards can have these options. The 
optional o-name option gives a name to 
the card. If a card has a name, the 
card can be referred to by a 
destination . 



25 



30 



35 



The o-next and o-prev give destinations 
for the NEXT and PREV keys. If omitted, 
the defaults are the next and previous 
sequential card in the deck. If o-prev 
is omitted from the first card, the PREV 
key returns to the deck last visited. 
If o-next is omitted from the last card, 
the NEXT key returns to the first card 
of the current deck. However, this 
default behavior is only a fail-safe: 
the last card in a deck should always 
have either an o-next option, or be a 
choice card where each choice entry 
indicates a new destination. 
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DISPLAY CARD 



10 



display- card 

display-header 
display-options 
display- content 

display- footer 



15 



::= display-header display-content 
display- footer 

= <DISPLAY option-list > 
= card-options 

= { softkey }* formatted text 
= < /DISPLAY > 

Display cards give information for the 
user to read. See. Formatted Text below 
for a full description of the format of 
information that can be displayed. 
Softkeys can be described for this card 
only, see Softkeys below. 



20 



25 



choice-card 

choice -header 
choice -opt ions 

o-method 
method- type 
entries 

choice- footer 



CHOICE CARD 
::= choice-header display-content 
{ entries } choice-footer 
: := <CHOICE ol { choice -opt ions } > 
::= card-options | o-method | o-key 
| o-default 

= methods method- type 
= number | list | alpha | group 
= { choice-entry }+ 

= { group-entry { choice-entry } + ) + 
= </CHOICE> 



30 



Choices let user pick one from a list. 
The initial display content is shown to 
the user, followed by the choices. Each 
choice can have one line of formatted 
text (which may be wrapped or scrolled 
by the phone if too long) . 



35 



How the choices are displayed and chosen 
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n 



is based on the o-method option. Note 
that this option is a hint only, and can 
be disregarded by the phone. The number 
method is the default and indicates that 
5 the choices are numbered sequentially 

from one and are chosen by pressing the 
appropriate digit on the keypad. If 
there are more than nine options, the 
phone may choose some other method of 

10 selection. The list method indicates 

that the list should be unnumbered and 
that the user should scroll through the 
list and hit some designated enter key 
to choose an entry. The alpha method is 

15 like list, only it is an indication that 

the text of the entries should be used 
to aid selection if at all possible. In . 
this case, the entries are assumed to be 
alphabetically sorted. The group method 

2 0 is described in more detail below. 

The o-key option indicates, if present, 
the key of an argument to be added to 
the argument list. See Arguments below 

2 5 for more information. The value of the 

argument comes from the choice entry; 
see below. The o-default option 
indicates the default value if the user 
just hit ENTER. See o-default under 

3 0 Entry Card below for more information. 

choice-entry :: = <CE ol (entry-options) > 
formatted- line 
entry-options ::= action-options | o-value 
35 Each choice has text displayed to the 

user. If the action-options are given, 
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the indicated action is performed if the 
choice is made. If the o-value option 
is present, it supplies the value to the 
argument identified with the o-key 
option in the choice header. If no o- 
value is given, the text of the entry is 
used (without any formatting) as the 
argument value . 



10 



group - entry 
group - opt ions 



15 



20 



::= <GE ol (group -opt ions) > 
::= label= value 

If the group method is used, the choices 
are divided into a number of groups. 
Each group is headed by a group-entry, 
which, via the label option, gives a 
short name to the group . The phone can 
then give the user .a hierarchial 
interface for choosing among a large 
number of choices . The text of the 
label should be limited to eight 
characters and may be truncated by the 
phone . 



25 



30 



entry-card 

entry- header 
entry- opt ions 

entry- footer 



35 



ENTRY CARD 
::= entry-header display-content entry- 
footer 

::= < ENTRY ol (entry-opt ions ) > 

::= card-options | o-format | o-key 

| o-default 
: : = </ ENTRY > 

Entries let the user enter a value. The 
display content is shown to the user, 
followed by an entry line. The user's 
entry is controlled by the format. The 
o-key option indicates the argument that 
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is being set by this entry. The value 
of the argument are the user's entry. 

o-format : : = f onnat= value { ; format-hint } 
5 format -hint :: = value 

This option specifies the format for 
user input entries. The string consists 
of format control characters and static 
text which is displayed in the input 
10 area. Most of the format control 

characters control what data is expected 
to be keyed in by the user. They are 
displayed as blanks until the user types 
into them. 

15 

The format codes are : 

A entry of any alphabetic 

character 
9 entry of any numeric character 
20 X entry of any alphabetic or 

numeric character 
*f allow entry of any number of 

characters; the next character, 
f, is one of A, 9 or X and 
25 specifies what kind of 

characters can be entered. 
\c display the next character, c, 
in the entry field; allows 
display of the formatting 
30 characters in the entry field. 

Format hints indicate what kind of value 
€ is expected. If a format hint is not 

understood, it is ignored. Currently 
35 defined format hints are: 
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text 



10 



mail -reply- 



address -list 



text is expected to be 
text, use special 
input techniques; 
generally follows *A 
or *X 

like text, but 

expected text is for 

an e-mail message or 

page; may affect input 

algorithm 

entry is a list of 

e-mail addresses 



o-def ault 



15 



: :- defaults value 

The o-default option supplies a value 
that is used if the user simply hits 
NEXT. If no default value is given, 
then the user must supply a value . 



20 



format ted- text 

formatted- line 
text-line 



25 



FORMATTED TEXT 

::= { { flow-image } { line-format } 
text -line ) * 
: : = text-line 

;:= { text | image | text -format | 
alignment -format } * 

Formatted text is what is shown to the 
user in most cards. Formatted lines are 
used for choice entries . 



30 



text -format 



35 



: : = <B> | <I> | <BL> 
: : = </B> | <I> | <BL> 

The format codes control Bold, Italic 
and Blinking. The slash versions cancel 
the formatting. Unlike HTML, these 
needn't be strictly nested and over 
application and over cancellation are 
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tolerated. Formatted- text and 
formatted- line elements start in plain 
mode (no bold, italic, or blinking) . 

5 alignment -format :: = <CENTER> | <BOLD> | <TAB> 

The alignment codes specify how parts of 
a line are to be laid out. The text 
following the alignment code is either 
centered or right justified on the same 
10 line as the other text. The text or 

image following the code is considered 
to be all text up to the next alignment 
code or line break. All lines start 
^ implicitly aligned left. Note that 

J 15 these do not include an implicit line 

M break so that one can have both left and 

'~ right justified text on a single line. 

M= If there is too much text and not enough 

: u room on the line then, if in wrap mode, 

5i 20 the non-fitting text is moved to the 

next line and aligned the same way. If 
in line mode, the line may end up 
s p running together with two spaces between 

:g; the left, center, and right justified 

2 5 segments. 

The tab code is used to create aligned 
columns. Rather than tab to specific 
character positions, the tab code 

3 0 separates the text for each column. The 

width of the column is determined by the 
maximal width of the text (or images) in 
each line. The extent of the columns is 
from the first line with tab codes 
35 through the last contiguous line with 

tab codes. Some lines may have fewer 
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tab codes than others, in which case 
they are assumed to have no text for the 
extra columns. 



line -format 



10 



15 



: : = <WRAP> | <LINE> 
: : = <BR> 

Multiple lines of text are separated by 
the <BR> code. If a line is too long to 
fit on the screen and, if in wrap mode, 
the line is word wrapped onto multiple 
lines. If in line mode, the line is 
left as one line and is scrolled 
horizontally. Formatted- text and 
formatted- line elements start in wrap 
mode and may be changed with either the 
<WRAP> or <LINE> codes. These codes are 
an implicit line break. 



20 



image 



flow- image 



25 



image - opt ions 
f 1 o w - i mage - opt ions 
inline-data 



30 



35 



IMAGES 

:= < IMAGE ol (image-options) > 
: = < INLINE ol (image -opt ions) > 
inline -data </INLINE> 
: = < IMAGE ol (flow-image-options) > 
:= < INLINE ol (flow-image-options) > 
inline-data </INLINE> 
= o-source 

= image -opt ions | o-flow 
= ASCII85 encoding of image data 



Images are treated as large words and, 
by default, are simply displayed as part 
of the text. Flow- Images have a flow 
option that causes them to be treated 
differently. The image data is stored 
in a separate data stream as identified 
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10 

o- source 
o-f low 



softkey 
softkey- opt ions 

30 
35 




15 



20 



25 



by the source option. 

Inline images are treated identically, 
only the data is part of the current 
data stream. ASCII85 is a standard way 
of encoding binary data in printable 
ASCII, whereby each four bytes of data 
is encoded in five characters. Note 
that TIL only uses inline images, and 
uses a different encoding. 

src= location 
This option specifies the location of 
the source for images. 

::= flow= { left | right } 

This option controls the alignment of 
flow-images. The option specifies that 
the image is flush left or flush right 
with the screen. Subsequent lines of 
text flow in the remaining right or left 
hand space . 

SOFTKEYS 

::= < SOFTKEY ol ( sof tkey-opt ions) > 

::= o-label | o-button | action-options 

Softkeys supply definitions for two 
buttons known as SOFT-L and SOFT-R. 
They do not show up in the normal text 
and graphics area displayed to the user, 
but on a separate line for soft key 
labels. (Note: in some implementations, 
where screen real estate is scarce, this 
label line may get used for normal text 
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and graphics display when there are no 
softkeys defined on the current card) . 

When the softkey is pressed, the 
indicated action takes place. 



o- but ton 
side 
o-label 



10 



^0 



15 



= buttons side 
= left | right 
= label= value 
The button option specifies which 
physical key the softkey applies to. 
The label option is the text that is 
displayed on screen for that key. The 
phone may truncate the label. It is 
suggested that labels be fewer than 
eight characters . 



20 



25 



30 



Softkeys can be specified both for the 
deck as a whole and per card. When 
specified for the deck (after the deck- 
header, but before the first card) they 
remain in effect for the entire deck. 
When specified for a card (at the 
beginning of the formatted- text for the 
card) , they temporarily override any 
deck softkeys while the card is visible. 
Note that the override is done 
independently for the two keys (a card 
can override one softkey, but not the 
other) . To override a deck softkey with 
no softkey (in effect, to remove a 
softkey for the duration of a card) use 
a softkey with no label and no action. 



35 



SYNTAX: 



OPTIONS 
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15 



ol (valid-option) 

option-list 
option 
key- 
value 



20 



25 



Many of the syntactic elements of PIDL 
have option lists associated with them. 
Options refine the operation of the 
elements they are part of. Unless 
otherwise noted, options do not nest, 
even when the same option is given in 
two nested elements. Options that are 
not defined for an element are ignored, 
even if valid for an enclosing element. 



{ blank-space valid-option }* 
{blank-spaces } 
= ol (option) 
= key = value 
= identifier 
= plain-text 
= " { text } " 
An option list contains zero or more 
options. Each option is separated by 
blank-space (required!) and optionally 
followed by blank- space . In the syntax 
diagrams, option lists are shown as: 
ol (valid-option) where valid-option is 
replaced with an element that defines 
the possible options in this context, 
ol is a generic syntactic description of 
option-lists . 



30 



35 



Each option is a key and a value. They 
may be given in any order within the 
list of options. The key is always an 
alpha-numeric name that is case 
insensitive. The value, if it is 
composed of only alphanumeric 
characters, may appear directly after 
the equals sign. Otherwise, the value 
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must be quoted. In quotes, blank- space 
is treated literally . and is considered 
part of the value. 



10 



15 



20 



destination 



25 



30 



location 

full-loc 

partial-loc 
relat ive- loc 



In the syntax diagrams, the possible 
values for various options are specified 
without quotes. However, quotes are 
always acceptable around an option 
value . 

Unlike almost all other syntactic 
elements, blank space is not permitted 
between the key and the equals sign or 
between the equals sign and the value. 

Many options have a more restricted set 
of possible values than represented by 
the above syntax. See the individual 
options for details. 



DESTINATIONS 

= location { ; animation } 
= card- loc { ; animation } 
= stack-operation { ; animation } 

= full-loc I partial-loc 
relat ive -loc 

= : service-id / deck-path 
= : service-host / deck-path 
= / deck-path 
* . / } * deck-path 



card- loc 



= # identifier 



35 



deck-path 
service- id 



:= plain-text { / plain-text }* 
:= % plain-text 
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service-host ::= plain-text 

Destinations are used in some options to 
indicate the next, or previous deck or 
card to show. A deck is specified 
5 either with a full location (service-id 

and deck-path) , just a deck-path (in 
which case the service is the same as 
the current deck's service), or a 
relative deck-path. In the later case, 
10 the last component of the current deck- 

path is removed, (and one additional 
component for each ../ in the relative 
deck-path) , and the deck-path appended. 

15 A particular card can be a destination 

and is specified by a card-loc element. 



stack-operation ::= + card-loc 

20 : := - 

In addition to the normal history list 
of * where a user has been that is kept by 
a phone, the phone also keeps a short 
stack of locations. Using a plus sign 

25 form causes the current location (deck 

and card, and location in the history 
list, and animation used) to be pushed 
on the stack. before going to the new 
card. Using the minus sign form causes 

3 0 a return to the location on the top of 

the stack, and the history list to be 
pruned back to the saved point. If no 
animation is given, the inverse 
animation is used. The stack is popped. 

35 

animation ::= slideN I slides 
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* 



10 



^4J 



15 



20 



= slideW | slideE 
= slideSW | slideNE 
- slideSE | slideNW 
= flipV 
= flipH 
= fade 
= none 

The optional animation argument 
indicates what form of screen animation, 
if available, is to be used when going 
to the destination. The animation is 
remembered with the destination in the 
history and destination stack. If the 
user moves to a destination via a 'go' 
or 'next' operation, then the animation 
is performed. If the user moves to a 
destination via a 'prev' or 'pop' 
operation, the reverse animation 
associated with the current location is 
performed . 



ACTIONS 



25 



30 



o-go 
o-call 



Choice entries and soft keys can specify 
actions to be performed when the user 
selects the choice or softkey. 
action-options ::= o-args | o-call 
| o-page 

::= go= destination 
: : = call= value 

The go operation indicates that the 
destination should be moved. 



35 



ARGUMENT PROCESSING 

Each time a deck is requested, arguments 
may be passed along with the request . 
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These arguments may be used by the 
service end to compute a deck specific 
for the user rather than just return a 
pre-written deck. 



10 



15 



Arguments are built-up as the user 
traverses the deck. Each argument is a 
key-value pair. While arguments 
superficially look like options, these 
two entities are quite; distinct: Options 
are a part of PIDL and affect the 
operation of the phone. Arguments are 
information gathered by the phone and 
returned to the service. Neither PIDL 
nor the phone understands the arguments 
beyond their basic syntactic structure. 



20 



25 



Arguments come from three places: Choice 
cards, Entry cards, and the args option. 
Each of these specifies a key-value pair 
that is added to a buffer of arguments 
to be sent . In the case of the args 
option, multiple arguments may be 
specified. When an argument key-value 
pair is added to the argument buffer, if 
the key is already present in the 
buffer, its value is replaced. 



30 



35 



o-args 
a r gume n t - 1 i s t 

arg- key- value 
arg-key 
arg-value 



::= args= arg-list 

: : = arg-key-value { { & 

key-value } * 

= arg-key = arg-value 
= identifier 
= plain-text 



Note: The entire o-args element is 
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actually the value of an option. If it 
has more than one arg-key-value it will 
need to be in quotes. Since the 
ampersand (&) and semi-colon ( ; ) are 
used as key- value pair separators, these 
characters cannot be part of argument 
values. 



10 



0 _ ke y ::= key= arg-key 
o-value ::= value= arg-value 

These options are used in choice and 
entry cards to specify the key and value 
for the arguments those cards set. 



15 



20 



25 



alpha 
numeric 
alpha -numeric 
hex 

blank- space 
space 
tab 
new -line 



BASIC ELEMENTS 

::= any alphabetic character 

: : = any digi t 

: : = alpha | numeric 

:: = numeric | any letter A through F, 
either case 

:: = { space | tab | new-line }+ 
: : = the space character 
: : = the tab character 
. . = t he carriage return character 
,-.:= the line feed character 
:: = the sequence carriage return, line 
feed 



30 



35 



word : := { alpha-numeric }+ 
identifier ::= alpha { alpha-numeric }* 
integer ::= { + I - } ( numeric }+ 

text : := any 7 -bit ASCII character except < 
>, ", or & 



< 



&quot ; 



& 
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|   

::= any ISO-Latin-1 named entity 
: : = &# hex hex ; 

In text, runs of blank-space are treated 
5 as single spaces and my be used as point 

for word wrapping. 

plain-text 

safe { alpha | numeric | safe }* 

::= $ | - | _ | @ | , | & | ! 
10 1*1. 

- TIL ENCODING 

Except where noted, TIL is identical to 
15 PIDL in structure. To translate PIDL to 

TIL several steps are conceptually 
needed (these may be done in one pass by 
a translator) : 

20 1. Escape characters with the high 

bit set . 

2 . Compress or remove all blank space 

where possible. 
3 . Tokenize comment elements with a 
25 single byte with the liigh bit set. 

4. Inline images. 

Fundamentally, TIL is just PIDL with 
certain common character sequences 
30 replaced by single bytes with the 

high-bit set. The first two steps above 
support this. Additionally, images are 
further compacted by including them 
inline in a dense format. 



35 



The tokenizing follows the encoding 
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given in the table below. Note that for 
purposes of element separation, the 
tokens that represent option key 
identifiers (with the equal sign) can be 
5 considered to include all preceding 

blank space. Similarly, the tokens that 
represent option values can be 
considered to include all following 
blank space. 

10 



1^3 

^0 
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<PIDL> 


90 


args = 


CO 


alpha 


EO 




</PIDL> 


91 


button= 


CI 


center 


El 




<DISPIjAY> 


92 


call = 


C2 


fade 


E2 




</DISPLAY> 


93 


cost = 


C3 


f lipH 


E3 


5 


<CHOICE> 


94 


def ault= 


C4 


f lipV 


E4 




</CHOICE> 


95 


f low= 


C5 


group 


E5 


up 


< ENTRY > 


96 


format= 


C6 


inline 


E6 


</ENTRY> 


97 


go= 


C7 


left 


E7 




<CE 


AO 


kev= 


C8 


list 


E8 


10 


<GE 


Al 


label= 


C9 


none 


E9 




< IMAGE 


A2 


method= 


CA 


number 


EA 




< INLINE 


A3 


name= 


CB 


right 


EB 




<SOFTKEY 


A4 


next = 


CC 


slideE 


EC 




<B> 


BO 


paqe = 


CD 


si ideN 


ED 


15 


</B> 


Bl 




CE 


slideNE 


EE 




<I> 


B2 


src = 


CF 


slideNW 


EF 






B3 


ttl = 


DO 


slides 


F0 




<BL> 


B4 


value = 


Dl 


slideSE 


Fl 




</BL> 


B5 






slideSW 


F2 


20 


<CENTER> 


B6 






si ideW 


F3 




<RIGHT> 


B7 












<WRAP> 


B8 












<LINE> 


B9 












<BR> 


BA 











25 
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APPENDIX II 
A COMPUTER PROGRAM TO GENERATE 
A LETTER FREQUENCY TABLE 
FOR USE IN THE PREDICTIVE DATA ENTRY PROCESS 
Unpublished © 1995 Libris, Inc. 



'/* This program opens a text file selected by the 

user, generates the frequency table for that file, 
and then writes the frequency table to another 
10 file also selected by the user. 



#include <stdio . h> 
j ftinclude <string.h> 

h ~- 15 #include <console.h> 

#include <assert . h> 



typedef unsigned char byte; 
20 typedef byte triplet [3] ; 

typedef byte tristorage [27] [27] [27] ; 

IncrementTrigram (triplet t, tristorage trigrams) 
{ 

2 5 byte * pb; 

asser&(t[0] < 27) 
assert (t [1] < 27) 
assert (t [2] < 27) 

pb = fctrigrams [t [O] ] [t [1] ] [t [2] ] ; 
30 if (*pb < 255) *pb = *pb + 1; 

return *pb; 



StoreTrigramValue (triplet t, tristorage trigrams, byte 
35 value) 

{ 
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assert (t [O] < 27) ; 
assert (t [1] < 27) ; 
assert (t [2] < 27) ; 

trigrams [t [O] ] [t [1] ] [t [2] ] = value; 

5 } 

byte FetchTrigramvalue (triplet t, tristorage trigrams). 
{ 

assert (t [O] < 27) ; . 
10 assert (t [1] < 27) ; 

assert (t [2] < 27) ; 

return trigrams [t [O] ] [t [1] ] [t [2] ] ; 

} 

15 byte DumpTrigram (triplet t, tristorage trigrams) 

{ 

byte value; 
assert (t [O] < 27) ; 

assert (t [1] < 27) ; - „ 

20 assert (t [2] < 27) ; 

value = FetchTrigramValue (t , trigrams); 
if (value != O) 

{ • ' . > 

printf ("%c%c%c = ", t [O] + 'a', t [1] + 'a', t [2] + 

25 'a'); 

if (value == 255) printf ("***") ; 
else printf ( "%3d" , value); 

} 

return value; 
30 } 

int IdFromChar (short c) 

{ 

c = tolower(c) ; 
35 if (c < 'a' || c > 'z') return 26; 

return c - ' a' ; 
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S 15 

25 
30 



AddChar (tristorage trigrams, triplet t, byte b) 



byte value; 
unsigned short r; 

assert (b <= 26); 

if (b == 26) { t[0] = t[l] = t[2] = 26; return; } 

t [0] = t [1] ; 
t [1] - t [2] ; 
t [2] = b; 

value = FetchTrigramValue (t , trigrams); 
if (value == 255) return; 



if (value > 64) { 

r = Random ( ) ; / . 

if (value > 192 r & OxEOOO) return; 

else if (value > 128 && r & OxCOOO) return; 

else if (value > 64 && r & 0x8000) return; 



StoreTrigramValue (t , trigrams, value + 1) ; 



int i, j , k; 
int x; 
triplet t; 
x = O; 

for (i = 0; i < 26; ++i) 
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for (j = 0; j < 26; ++ j ) 
for (k = 0; k < 26; ++k) 
{ 

byte value; 
t [0] = i; 
t[l] = j; 
t [2] = k; 



10 value = DumpTrigram (t , trigrams); 

if (value == 0) continue; 
if (++x == 6) { 

printf ("\n" ) ; x = 0; 

15 } 

else 

printf ( " » ) ; 



20 



} 



} 



OSErr BuildTrigram ( short refNum, tristorage trigrams) 

{ . ' 

OSErr err; 
triplet t; 
25 t [0] = t [1] = t [2] = 26; 

while (true) 

{ 

long count =80; 
30 char buf [80] ; 

int i ; 



err = FSRead (ref Num, &count 7 buf ) ; 
if (count == 0) return err; 
3 5 for (i = 0; i < count; ++i) { 

AddChar (trigrams, t, IdFromChar (buf [i] ) ) ; 
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} 

if (err) return err; 

} 

return 0 ; 

5 } 

Handle OpenTrigrams (void) 

{ 

OSErr err; 
10 OSType type; 

StandardFileReply reply 

short refNum; 

short id; 

Handle h; 
15 Str63 name; 

tristorage *trigrams; 



type = 'TEXT' ; 

StandardGetFile (nil, 1, &type, &reply) ; 
20 if (! reply . sf Good) return .nil; 

err = FSpOpenDF ( &reply . sf File , fsCurPerm, fcrefNum) 
if (err) return nil; 



25 



memcpy ( name , reply . sf File . name , sizeof (name) ) ; 
h = NewHandle (sizeof (tristorage) ) ; 



HLock(h) ; 

30 trigrams = (tristorage *) (*h); 

memset (*trigrams / 0, sizeof (tristorage) ) ; 



BuildTrigram (refNum, *trigrams) ; 
FSClose (refNum) ; 
35 DumpTrigrams (* trigrams) ; 

HUnlock (h) ; 
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type = ' rsrc' ; 

StandardGetFile (nil, 1, &type, &reply) ; 
if (! reply . sf Good) return; 

refNum = FSpOpenResFile ( &reply . sf File , fsCurPerm) 
5 if (refNum == -1) return; 

UseResFile (refNum) ; 

id = UniquellD ( ' smrt ' ) ; 
//id = 128; 
10 AddResource (h, 'smrt', id # name) ; 

UpdateResFile (refNum) ; 
FSClose (refNum) ; 
return h; 



15 



20 



} 



main ( ) 

{ 

OSErr err; 
Handle h; 



cshow (stdout ) ; 
TEInit () ; 
InitDialogs (OL) ; 
InitCursor () ; 
2 5 h = OpenTrigrams ( ) 
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